On Thu, 2004-06-24 at 10:25, Patrick A wrote:
> Been a while since I've Perl'd, but doesn't it make more sense to pass a
> reference around? or to have an imagemanager that your threads can query?
Within the same thread, yes. Unfortunately, references created in one
thread can not be shared with another thread (you can not assign a
reference (this included bless'ed objects) to a shared variable), and
although I can pre-allocate surfaces before I start up threads (which
makes them visible in all threads, this doesn't make it as dynamic as I
want. In addition, the visibility of pre-allocated variables (and
associated memory) in perl may be a side effect of the underlying
threading model on the platform I happen to be using -- which doesn't
make the script very portable.
> you're making a surface, then you're copying it's innards to a variable,
> then you're copying it onto another surface. That's 3 times the bloat you
> probably don't need if you can work out an imageManager system.
>...
> If you don't know what I mean by image manager:
>
> an image manager is a class(or what not) with methods for loading and
> returning images. So that all you need to do is pass the image manager an ID
> or file name. If it's not loaded, the image manager loads it and returns the
> reference, or, if it's already loaded, it just returns the reference. It's
> faster and takes less memory.
The surfaces don't exist outside the program -- I want worker threads
draw on them and the main thread to blits surfaces on the application
window; each time they are blitted to the application window, they'll be
different, so keeping references around as part of a factory (under the
guise of reducing bloat in the case where a surface might be reused)
doesn't help in this case. Once they are drawn on the application
window, there is no need to keep them around.
Although, if I did apply something like am image manager or factory, the
"bloat" would move from being in memory (as the surface is serialized
and unserialized) to on disk (using the "load from file" example -- but
the amount of bloat stays the same -- because of the nature of the
process I'm trying to implement.
Logically, I need to do a memcpy between the visible variables in
different threads, where the variables/memory in a thread are invisible
to the variables/memory in another. Physically, because I can not share
references in perl threads, this needs to be done by copying the
variable to a temporary area that can be shared (serializing and storing
in a scalar) and then copying it out of the temporary area into memory
in the destination thread.
Re: "faster"/speed/CPU usage -- I'm banking on the fact that having
threads wakeup to generate surfaces when necessary is less work than
having a single threaded application that needs to keep track of what
needs doing when and interleaves surface creation with event acceptance
and dispatch.
> but again, I haven't Perl'd in a while, and I've never messed with
> multithreading in Perl, so feel free to correct me or tell me to stfu :)
Your message has been enlightening and has given me some ideas. I'm
going to see if I can do some tricks with pack/unpack to get the surface
data out. Alternatively, I can try to get some stuff stored in SysV
shared memory, although I think this is a dead-end (as it would require
too much modification to the XS, XS programming is something I'm only
beginning to fully understand). In addition, using temporary files to
write BMP files to disk and reloading in another thread may be viable,
although I'm not a big fan of the BMP file format (which is the only one
supported by SDL for saving, I believe) but using an in-memory file to
store the data and such may workout. There might be some use in the
SDL_image library, although I don't see any support for saving.
--
Andy Bakun: get used to it
<[EMAIL PROTECTED]>
