Upgrading from 0.9.30 to 1.0 6 slowed my game's graphics by about 100
times!
lazarus / 39-Graphics

----------------------------------------------------------------------
Clover · 2013-02-20 23:34

After finally upgrading my Lazarus to 1.0.6 my puzzle game now runs
like treacle. I managed to trace the culprit to TPaintbox.Update.

This used to go to TControl.Update but now goes to
TGraphicControl.Update and I see that somebody changed this procedure
to invalidate the entire parent's clientrect. So now, since my
Paintbox is the entire screen, Windows updates the entire screen
instead of just my small invalidated region, with devastating
consequences. (See http://lists.lazarus.freepascal.org/pipermail/lazar
us/2011-June/063858.html for the change).

I guess I don't really understand why that change was made but anyow,
can anyone suggest a way for me to workaround this change? In other
words call TPaintBox.Update but only have my invalidated region
updated. Thanks!

~ David

----------------------------------------------------------------------
Martin_fr · 2013-02-20 23:42

try

uses LCLIntf;

var
 r: TRect;

    r.Top := ...
   r.bottom left right ...
    InvalidateRect(PaintBox.Handle, @r, False);

----------------------------------------------------------------------
Clover · 2013-02-20 23:49

Thanks, but I'm already doing that to invalidate my region. Then I
call PaintBox.Update, to get the operating system to update that rect
on the screen. The problem is, the new Update procedure is now forcing
an Invalidate of the ENTIRE parent clientrect, instead of my small
invalidated rect.

Here's the TGraphicControl.inc procedure that appears to be causing me
grief:

procedure TGraphicControl.Update;
var
  R: TRect;
  Pt: TPoint;
begin
  if Assigned(Parent) and Parent.HandleAllocated and Parent.Visible
then
  begin
    R := ClientRect;
    Pt := Parent.GetClientScrollOffset;
    OffsetRect(R, Left - Pt.X, Top - Pt.Y);
    R.Right := R.Right + Pt.X;
    R.Bottom := R.Bottom + Pt.Y;
    LCLIntf.InvalidateRect(Parent.Handle, @R, True);
  end;
end;

----------------------------------------------------------------------
Martin_fr · 2013-02-21 00:21

Oh, I see.

UpdateWindow(PaintBox.Parent.Handle);


also  in LCLIntf

----------------------------------------------------------------------
Martin_fr · 2013-02-21 00:26

The new behaviour looks wrong to me.

I will enquire with the author

----------------------------------------------------------------------
Clover · 2013-02-21 09:39

Quote from: Martin_fr on February 21, 2013, 01:21:10 amOh, I see.

UpdateWindow(PaintBox.Parent.Handle);


also  in LCLIntf


Perfect, thank you so much. My graphics are flying once more.

----------------------------------------------------------------------
Clover · 2013-02-22 11:22

Quote from: Martin_fr on February 21, 2013, 01:26:16 amThe new
behaviour looks wrong to me.

I will enquire with the author

It must be wrong because

(a) it subverts the caller's invalidated region, undermining the whole
point of invalidated regions and

(b) it doesn't actually force a repaint, which is the whole point of
Update.

This is how Delphi describes TControl.Update and how it used to work
in Lazarus 0.9.30 before this change:

Processes any pending paint messages immediately. Call Update to force
the control to be repainted before any more, possibly time-consuming,
processing takes place. Use Update to provide immediate feedback to
the user that cannot wait for the Windows paint message to arrive.

Update does not invalidate the control, but simply forces a repaint of
any regions that have already been invalidated. Call Repaint instead
to invalidate the control as well.

I can't believe I'm the first person to notice this massive slow down
(and lack of immediate repaint). I guess nobody else uses Update. In
the Mac edition of my game I found it absolutely essential to use
Update. Lucky for me this change was not already in 0.9.30 (I think it
just missed it) when I started using Lazarus to port my code from
Delphi, or I may have abandoned it as being too slow.

~ David

----------------------------------------------------------------------
Martin_fr · 2013-02-22 16:13

Yes, the docs where the first thing I checked myself.

Nevertheless, even simple things need a  moment of spare time. I
reverted the change in trunk, and will (at the next occurrence of
spare time) merge it to fixes. So it should be in the next release.

----------------------------------------------------------------------
Clover · 2013-02-22 19:32

Many thanks for your help.

In the meantime, since I use Update in several places, I just added

Inherited; Exit;

on the first line of that procedure to temporarily revert it locally.