Re: [AD] per-thread transformation and blending mode

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Thu, 2010-06-24 at 13:59 -0400, Pavel Sountsov wrote:
> 
> On 06/24/2010 09:49 AM, Peter Wang wrote:
> > Recall that I'm working on eliminating the "current display", as I
> > believe this makes the API much clearer.  Recall also that when you draw
> > something, the transformation/blending mode are taken from the current
> > display -- except when there is no current display, then the
> > transformation/blending mode come from the thread.  (I say "recall", but
> > I didn't really understand this that well before :)
> >
> > Previously, you could almost ignore that.  Most of the time you only
> > have a single display, so targeting different video bitmaps wouldn't
> > change the current display, and hence the transformation/blending.
> > And when you target a memory bitmap nothing would change either because
> > the bitmap doesn't belong to any display.
> >
> > If you replace the "current display" with the "currently targetted
> > display" (i.e. the display that owns the target bitmap), this scheme
> > leads to confusing behaviour.  When you target a video bitmap, you take
> > the transformation/blending from the target display.  But when you
> > target a memory bitmap, there is no target display, so the
> > transformation/blending has to be taken from thread-local state.

Another idea would be to keep it per-target-bitmap. For example if you
use transformations to make the coordinate system go from 0,0 to 1,1 for
the whole backbuffer it would be annoying if you have to reset it each
time you switch back from drawing to another bitmap.

> >
> > One solution is to roll back part of the change, so that when you target
> > a memory bitmap you still take the transformation/blending from the
> > previously targetted display.
> >
> > But perhaps it would be clearer to make transformation/blending always
> > per-thread state?  Whatever bitmap you target, the settings that were
> > set in the current thread will apply, and it doesn't matter what display
> > the bitmap does or doesn't belong to.
> >
> > Peter
> 
> I agree mostly... the thread-local and display-local divide is a little 
> confusing, so cleaning it up like that would only simplify the situation 
> for the user.
> 
> Do you have any plans for deferred drawing also? It's the other 
> display-local feature other than transformations and blending.
> 

I think changing the target bitmap while deferred drawing is on should
not be permitted. With that you always have to call
al_hold_bitmap_drawing(0) before al_set_target_bitmap and
al_hold_bitmap_drawing(1) afterwards to turn it on again for the new
bitmap. Where we store the flag internally therefore does not matter
(global TLS or in the bitmap's display or the per-thread dummy display).

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>