[Lazarus] Getting update rect/region in Windows

[Max Vlasov]

On Mon, May 23, 2011 at 12:43 AM, Hans-Peter Diettrich <DrDiettrich1 at aol.com
> wrote:

> Max Vlasov schrieb:
>
>
>  Ok, another example. Imagine that two alpha png is merged and drawed on
>> the form on the fly.
>>
>
> Is that on-the-fly merging really necessary?
>
>
>  And you drag a small window over this form. My experience tells me that
>> win32 will do great automatic job of narrowing the final drawing of the
>> bitmap to smallest rectangle possible, but my internal procedures of
>> alpha-blending can get this information only from
>> GetUpdateRect/GetUpdateRgn, otherwise every single pixel moving of this
>> window will lead to full alpha-blending of these bitmaps. ClipRect won't
>> provide this information
>>
>
> I'm not sure what you mean. When the dragged window also uses
> alpha-blending, then Windows (GDI) must do that job. Using GetUpdateRect IMO
> should not work, because BeginPaint restricts output to the ClipRect.
>
>
> DoDi
>
>

I must admit I was wrong saying that ClipRect doesn't provide the
information about updating areas. It does, partly my misunderstanding came
from the naming change in Delphi. Usually win32 rect/region api functions
comes in pairs with similar names, but ClipRect property is not a call to
GetClipRect (there's no such function), but to GetClipBox function that is
just partly related to clipping regions. And Luiz is also right referring to
rcPaint member. So if one needs the update rect, there are plenty of options
already.

Actually I needed access not only to update rect, but to the update region
(for example in order to effectively resolve small rectangles in different
areas of a big window). In this case I also found a replacement for
GetUpdateRgn, it's GetRandomRgn, documented not so long ago (so I was not
aware of its existence) and according to the help it contains the correct
region not only before, but also after BeginPaint. So I will probably use
this one instead of windowproc hacking

As for necessity for on-the-fly drawing, I usually pay much attention to
resources used and don't allocate much unless is necessary. The system
working on the fly consumes much less memory because doesn't use
intermediate buffer. Sometimes it even can not use bitmaps at all (regions
filling/framing) So there are several approaches, I think they all have
their rights to exist.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110523/963b289a/attachment-0003.html>