Re: [interface-announce] info/CWS aw033 : add: Window::PrePaint()

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [interface-announce] info/CWS aw033 : add: Window::PrePaint()

Thorsten Behrens-3
On Thu, Jul 03, 2008 at 06:32:25PM +0200, [hidden email] wrote:
> CWS aw033 adds a virtual PrePaint handler to Window. PrePaint will be
> called immediately before a paint and will allow to invalidate some
> additional regions that will be updated in the following paint.
>
Hi Philipp,

just curious - could you elaborate a bit why this was necessary?

TIA,

-- Thorsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [interface-announce] info/CWS aw033 : add: Window::PrePaint()

Armin Le Grand
    Hi Thorsten,

Thorsten Behrens schrieb:

> On Thu, Jul 03, 2008 at 06:32:25PM +0200, [hidden email] wrote:
>  
>> CWS aw033 adds a virtual PrePaint handler to Window. PrePaint will be
>> called immediately before a paint and will allow to invalidate some
>> additional regions that will be updated in the following paint.
>>
>>    
> Hi Philipp,
>
> just curious - could you elaborate a bit why this was necessary?
>  
Well, i can :-)

It is for optimizations in aw033. Imagine an object change. Normally,
You need to invalidate the current BoundRect and the new BoundRect. This
needs to be done for each object change, regardless when the next
repaint occurrs. The expensive step here is to get the BoundRect for the
new position. This involves generating new sequences of properties which
will not be decomposed since the object did change. Getting the
BoundRect now involves getRange() with the newly created sequence of
properties which will decompose those down to the next primitive with
::getRange implementation.
Since we have actions with thousands of ObjectChanges before repaint and
not cheap decomposable objects (e.g. 3D scenes), this can get expensive.
As You know, a former try of me was to use ExpandPaintClipRegion in the
next paint. This works, but is just too complicated and error-prone,
especially when need to combine ClipRegions given into the paint by the
seven Applications. I think we should remove that one again, it's more a
kind of h**k.
The idea was to use a 'LazyInvalidate (tm)' which only invalidates the
start situation (to trigger the repaint) and sets a flag at the OC that
not all invalidates from VOCs are up to date (actually, this flag is a
VCL timer in the OC implementation for SdrPaintView). Nothing will be
invalidated on following ObjectChanges, so no BoundRect calculation and
sequence of primitive creation needed.
At the next paint, there were two alternatives before this change:
(a) Collect the BoundRects of the not-current objects and
ExpandPaintClipRegion
(b) Collect and invalidate in the paint
As explained, (a) is error prone and a kind of a h**k. On the other
side, (b) works, but needs two repaints where the in-between state e.g.
shows a half-moved object for a short period of time.
Thus, i discussed with PL and we invented the PrePaint VCL Window event.
It will be triggered right before the paint, but before VCL goes into
the critical state with prepared ClipRect and bInPaint flag set, so it
is possible to trigger invalidates.
The PrePaint is forwarded through the applications and triggers
eventually existing lazyInvalidates. The paint will be complete, VCL
will create the correct ClipRegion and this will be fed to the
application's paint which partially react on it (one of the big problems
with (a)...).
Of course support for PrePaint is not needed, fallback is (b) which
works well. I will implement and forward the PrePaint call for the 'big'
applications for performance and better visualisation. All other
VCL-windows users will work unchanged even when using DrawingLayer.

PL also mentioned that there may be other usages...

> TIA,
>
> -- Thorsten
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]