On Feb 12, 2008 9:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:
The problem with OpenGL is, that GL context state is not a simple
thing, which can be switched quickly.
The drawing pipeline could be very complex, and if you allow multiple
processes to issue drawing commands, it almost guaranteed that you
will break things.

Let me illustrate a problem.
Suppose you have a Device, which provides a canvas which can be used
to draw on it.

canvas := Device getCanvas.  " device at 'safe' state here "
myVisuals drawThingsUsing: canvas.  "device is not safe during drawing "
" we finished drawing, now we are safe "

.. the main problem, is that when you received a canvas instance you
can free to do something like:

canvas := Device getCanvas.
1 to: 10 do: [:i | [ (self at: i) drawOn: canvas ] fork ].

and at this point you are not safe anymore. You can easily break
Device state, if multiple processes will try issue different drawing
commands using canvas.

I really don't like putting semaphores everywhere. It will be a
performance killer.

One way to isolate things, is to provide protocols like:

Device drawExclusively: [:canvas | .. drawing code here .. ].

but again, this is not guarantees that, developer will not use
received canvas reference to do nasty things..
Do an active process check in all methods of canvas?
Any ideas?


Lots, but it depends on what the problem actually is. Could you describe it in more detail?

One option is to modify Canvas (or a subclass) to have a getLock method which returns a Mutex (aka Semaphore) unique to that Canvas. Your code can then do "mutex critical: [...]" blocks to assure atomicity.

However, it would seem to me that the problem is with the user of the Canvas. With any canvas, you need to issue the drawing instructions in the right order to preserve the z-index of the elements added. It's the user who must make sure that it does not have two threads drawing in the same Rectangle concurrently.

Don't be sparing with the use of Semaphores. Correct code is better than fast code.

Gulik.


--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/