need opinions regarding use of slave interpreter ...
sp...@controlq.com
I've never had the need to use slave interpreters, and so I'm looking for
some opinions for their suitability in the following application ...
I'm playing with an image application which creates thumbnails for photo
images, some as large as 10 or 12MB each, and directories which may
contain 100 or more of these files, and so I'm toying with an image cache
and ways to optimize the thumbnail creation, which is a relatively slow
operation.
As I have never used slave interpreters, I'm a little fuzzy on whether
they might not be the way to go. I have a cache array which contains
label widgets with the -image set to the thumbnail, and currently allow
the user to select the cell size of the display table which shows them.
For instance, the default is a 3x3 grid (which will go up to 9x9 if the
user wishes, and can actually see anything that small) on a tktable which
is fixed in size at approximately 2/3's of the total screen size.
If the user changes directory, then the cache is invalidated, and we start
over creating the thumbnails. If he/she simply changes the number of
cells visible, we pick up where we left off, change the table geometry,
calculate a new table cell size, display the existing images, and then
start creating images for the newly visible thumbnails.
Is the cache management something which can be fobbed off onto an
asynchronous interpreter, have it update a status bar in the parent, and
display the images as they are created from the slave??
I'd prefer not to introduce threads, if I can help it, I was just
wondering if I could use slave interpreters to implement a poor man's
thread without increasing the complexity of the application too much.
Thanks in advance for any pointers/opinions ...
Cheers,
Rob.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Michael Schlenker
as threads by the thread extension can be asynchronous.
So i would say no for this usecase of slave interpreters, it would be a
valid usecase for threads or a seperate process on a pipe which does the
work of creating the thumbnails.
Slave interpreters are a nice way to implement things like user scripts
that are not allowed to introspect your application or other restricted
environments like plugins (see for example the pluginmgr package in Tcllib).
Michael
sp...@controlq.com
On Sat, 18 Nov 2006, Michael Schlenker wrote:
> Slave interpreters aren't asynchronous by default, interpreters created
> as threads by the thread extension can be asynchronous.
>
> So i would say no for this usecase of slave interpreters, it would be a
> valid usecase for threads or a seperate process on a pipe which does the
> work of creating the thumbnails.
>
> Slave interpreters are a nice way to implement things like user scripts
> that are not allowed to introspect your application or other restricted
> environments like plugins (see for example the pluginmgr package in Tcllib).
>
> Michael
>
Ahh, the light clicks on ... I'll sit down and re-architect.
I suppose another way to come at this is to instantiate the thumbnails for
the visible page only, though I'll likely have to go to the man pages ...
I suspect that tktable will throw an event I can bind to .... I'll study
the man page to see what falls out ...
Thanks for the input Michael!!
Cheers,
Rob.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
Darren New
> I suppose another way to come at this is to instantiate the thumbnails
> for the visible page only, though I'll likely have to go to the man
> pages ... I suspect that tktable will throw an event I can bind to ....
> I'll study the man page to see what falls out ...
I would do one thumbnail in an [after] event, update the screen, and
then decide which thumbnail to do next, doing one at a time in the event
loop. Add the thumbnail image to an array/dict/hash keyed by the file name.
If the user scrolls, or changes directories, just start working on
whatever is visible. When you're done the directory, go back and scan
for changes to files based on the date modified perhaps, and prune out
any images that are not in the current directory, if you need the memory.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Cameron Laird
<sp...@controlq.com> wrote:
>
>On Sat, 18 Nov 2006, Michael Schlenker wrote:
>> Slave interpreters aren't asynchronous by default, interpreters created
>> as threads by the thread extension can be asynchronous.
>>
>> So i would say no for this usecase of slave interpreters, it would be a
>> valid usecase for threads or a seperate process on a pipe which does the
>> work of creating the thumbnails.
>>
>> Slave interpreters are a nice way to implement things like user scripts
>> that are not allowed to introspect your application or other restricted
>> environments like plugins (see for example the pluginmgr package in Tcllib).
>>
>> Michael
>>
>
>Ahh, the light clicks on ... I'll sit down and re-architect.
>
>I suppose another way to come at this is to instantiate the thumbnails for
>the visible page only, though I'll likely have to go to the man pages ...
>I suspect that tktable will throw an event I can bind to .... I'll study
>the man page to see what falls out ...
>
>Thanks for the input Michael!!
.
.
I thought there was an FMM write-up (in the Wiki?) on how
interps do NOT give asynchronous processing. I don't find
it. 'Anyone else know where it is?
sp...@controlq.com
On Sun, 19 Nov 2006, Darren New wrote:
> sp...@controlq.com wrote:
>> I suppose another way to come at this is to instantiate the thumbnails for
>> the visible page only, though I'll likely have to go to the man pages ... I
>> suspect that tktable will throw an event I can bind to .... I'll study the
>> man page to see what falls out ...
>
> I would do one thumbnail in an [after] event, update the screen, and then
> decide which thumbnail to do next, doing one at a time in the event loop. Add
> the thumbnail image to an array/dict/hash keyed by the file name.
>
> If the user scrolls, or changes directories, just start working on whatever
> is visible. When you're done the directory, go back and scan for changes to
> files based on the date modified perhaps, and prune out any images that are
> not in the current directory, if you need the memory.
Indeed, using the event loop to good purpose only makes sense. Of course
processing a thumbnail will have a 1:1 correspondance with update, in
order to see that things are moving along ... but the thumb image array
will likely be sparse if the user is "clicking about". Likely a feature
rather than a glitch.
I'll play with this approach until I get something which is pleasing to
the eye. Thanks, Darren.
Cheers,
Rob.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Darren New
> I'll play with this approach until I get something which is pleasing to
> the eye. Thanks, Darren.
Sure thing. BTW, two other things you might want to consider, depending
on your app:
1) Store the thumbnails in a file when you exit, and then read them back
and toss any for files with different dates when you start up. (I have
a dir I've been working on with 3300 images, and pulling the thumbs out
of the file takes 20 seconds and regenerating them takes an hour.)
2) Don't toss thumbnails if you don't need to. Nothing more annoying
than to wait 90 seconds for thumbnails, click one pixel off from where
you meant, and having all that tossed.