|Re: Detect a control is visible and skip drawing [message #856357 is a reply to message #856065]
||Wed, 25 April 2012 15:36
| Grant Gayed
Registered: July 2009
The OS takes care of considerations such as whether a control is |
partially obscured, etc. You should only receive an SWT.Paint callback
if painting _needs_ to be done, and the Paint event's clipping bounds
should indicate the specific region needing to be painted. Any
optimization beyond this is up to the app (eg.- not re-computing
font/color info on every Paint call, only doing the work necessary to
paint the area that's included in the clipping region, etc.).
On 4/25/2012 6:35 AM, Leung Wang Hei wrote:
> What about if the widget is in a visible state but being obscured by
> other windows (from the same app or other app, java or non-java)?
> I suppose the OS is smart enough to skip the actual redraw but preparing
> all font/colour, creating/disposing GC/clipping all do add penalty,
> which is totally unnecessary.
> On 4/25/2012 1:27 PM, Ludwig Moser wrote:
>> i was in need for a similar problem, so i submitted a
>> actually i was flamed within a few hours, because changing the visible
>> flag of a control by a layout seems to be 'forbidden' or bad coding.
>> so i wrote my own layout and i am happy with it.
>> mine is based on gridlayout and automatically hides (no drawing) any
>> fields with isVisible = false
>> as additional goodie you can sort the components without removing and
>> adding them to parent. (also here i got flamed because i am using an
>> integer value, which is NOT unique - but it does what is shall do, sort
>> the components in correct order. if there are two of a kind its the
>> programmers fault and does not affect the algorithm in a bad way.)
Powered by FUDForum
. Page generated in 0.02243 seconds