[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XAAES slow?



Hi!

I must say that all in all you are right that it seems not to be a best practice to use wind_calc() in an existing window context. But read on please...

Odd Skancke wrote:
But this situation doesn't happen in WinDom. The wind_calc() is used every time you do WinDom equivalent of wind_get( WORKXYWH ) so the theme change will be accomodated appropriately.

 My arguments are based on situations where theme changes does not
affect already created windows (which must be specifically supported by
each application). In this case wind_calc() will return wrong (current
theme) deltas instead of the (previouse theme) deltas that were
effective at the time the window was created. So yes, this situation
will arise as WinDom handles things now.

Ok, this way it would not work obviously.

 I still would like to see WinDom use wind_get/set() to gather info
about existing windows. Why the use of wind_calc() at all regarding
existing windows when wind_get/set() exists?

I think it is possible to use the wind_get() in the place I am talking about in WinDom. It is now just an implementation dependency as WinDom implements some AES features when those are missing in the AES in use (toolbars and window menus). I will keep an eye on that (or someone in the WinDom list as I am hading out for the next weeks) and eventually avoid this I believe.

Have you had a look into the CVS when you say it would not cope with such a situation actually (I have sent the URL here previously http://windom.sf.net)?

 Ah, it is available via CVS :) Didnt know that.

You didn't bother to click on the link ;)

 And since I cannot see any other use for wind_calc() than calculate the
deltas of a 'virtual' window, it will work on the theme in use, because
its results are supposed to be used to create a new window _now_ (with
the current theme).

Hmm, what about the following:

switch( evnt_messag() )
  case WM_SIZED:
give_me_work_rectangle() to optimize further redraws and setup all coordinates now rather than doing this in the WM_REDRAW where this doesn't belong to. * for one example let say I have a lot of elements that need to recompute on window size/position change and I need this to be handled before I do the redraw...

Would we need an extended API to do wind_calc() in the particular window context to accomodate theme changes?

 Why cant we just accept that wind_calc() should not be used to gather
info on existing windows? Because it works on all other AES's? This is
the very definition of a HACK in my opinion, "wow, works! lets forget
documentation, propably there is no future either"

Which documentation states when _exactly is the wind_calc() to be used_ as opposed when it _can_ be used? IIRC no documentation ever gave us this information until now.

Anyway the compendium states the following (which is very similar to the problem we have - no particular window context available):

Comments       wind_calc() is unable to calculate correct values when
               a toolbar is attached to a window. This can be corrected,
               though, by adjusting the values output by this function
               with the height of the toolbar.

Thanks for making it clear.

Standa