Recent

Author Topic: Resize  (Read 948 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Resize
« Reply #15 on: June 26, 2022, 01:46:06 pm »
Anyway now I need help in case of real resizing, since in this case I need hard-recomputing, I am looking for something that works "after" resizing is complete (eg when the user resize the form with mouse I would like to do a single Hard-refresh at the end of user interaction).
It's impossible to know. Example: The user grabs the edge of the form, and slowly resizes pixel by pixel. When is the resize finished? When the user takes more than 1 second, between two increases? Or half a second? or 2 seconds?...

You could go for on mouse up. I am not sure you can reliable catch that on all OS.
And then, resize could (on some OS) end by the escape key. Or "alt-tab" switching to another window. Or....


Quote
It avoids the continous hard-recomputing in the refresh (even if not real resizing is happening, this part for me it is still obscure)).

Earlier you said "repaint". Not sure of your implementation. But you should use "Invalidate". Though that is only part of what you may need.

Invalidate, will schedule a paint event. However, if there are more resize events, and there is no time to paint, then resize events should afaik be handled first. And one combined paint at the end.

However it is imperative, that paint events are fast. If you put big computation in there, the effects can be visible bad.

So you should split
- the work to compute what should be painted (which can potentially take a long time)
- painting the result (i.e. copy a bitmap, or output text at the pre-determined position, or....)

If you do that split, the the question is, where to put the computing so that no blocking happens.

Threads is one possibility.
- But needs careful syncing / and caching, so you have "data in progress" in the thread and "previous-finished-data" to paint.
- Need checking, if the size further changed => so they abort any no longer needed work.

Or you can
- compute in QueueAsync or OnIdle
- only compute small part in each call, and then schedule the next QueueAsync or OnIdle.
  (you need state keeping, what has been done, and where to continue)
- if the size further changed, discard the partial work, and start over
  (or keep the partial work, if it can be used for some partial updated paint)

jamie

  • Hero Member
  • *****
  • Posts: 4667
Re: Resize
« Reply #16 on: June 26, 2022, 03:22:07 pm »
@wp I did some change, now it works "quickly" after moved the logic in DoOnResize.

It avoids the continous hard-recomputing in the refresh (even if not real resizing is happening, this part for me it is still obscure).

Anyway now I need help in case of real resizing, since in this case I need hard-recomputing, I am looking for something that works "after" resizing is complete (eg when the user resize the form with mouse I would like to do a single Hard-refresh at the end of user interaction).

thank you in advance.

 There was a correction made to the OnReSize event in the trunk and I thought it made it in recent releases? The OnResize behaves like it should now, that is, when the user releases the mouse you then get the response.
   Before that, when I reported an issue of another, that Resize event would get called always while dragging your form around and most likely due to the reason Delphi does it because of a hack they did years ago back in the old windows 3.x days where there wasn't any proper messaging taking place for users dragging along.

  I believe it was in the years of 16 bit to 32 bit apps.

 So the WM_SIZE event would come in when the user got done dragging their window frame around at which point you could respond to that.

 Today we have extra messages like WM_WindowPosChanging and ....Changed. which can give you that smooth response. Not only that, you can adjust the window size on the fly before it gets applied. This makes for a very smooth translation of sizing with no drawing artifacts.

 You also have messages like WM_MOVING and WM_SIZING which for some reason LCL does not allow through the class but is doable via a nice little unit I have to make it easy to process that message, too.

 So you could trap that message for the time being and detect if the user still has the mouse down.
The only true wisdom is knowing you know nothing

Paolo

  • Sr. Member
  • ****
  • Posts: 315
Re: Resize
« Reply #17 on: June 26, 2022, 07:35:54 pm »
First of all thank you all @wp, @Martin and @Jamie, for the suggestions.

I admit I was a little misliding in my components description, I wrote the code some years ago and I forgot the details  :-[

I'll came back here after re-assess the situation, here bleow just some comments.

Quote
So you should split
- the work to compute what should be painted (which can potentially take a long time)
- painting the result (i.e. copy a bitmap, or output text at the pre-determined position, or....)

I have already something similar. I wrote on a hidden bitmap and then display it. My "paint" logic (in the override paint procedure) is based on an internal flag that says if the bitmap has to be fully redraw (eg scales are changed, the plot itself is changed,...) or just show the bitmap as is.

So once the graphical elements are plotted the flag is set to "no-full-repaint". By user interaction there could be need of full-repaint but it is easily detected (ie change in data to display, change in scale,..) and a full-repaint (if needed) can be invoked by code.

But in case of "resize" (I initially wrote an override resize procedure) the flag is set set to full-repaint since the the size is changing!
this means that longer time is required (ie the bitmap is fully repainted due to "size" changes -> this was what I wrongly call "hard-recomputing", data are already there they need to transformed in graphical elements). And this causes slow repaint.

But as said before let me double check and better testing before adding other comments.



 

TinyPortal © 2005-2018