Re: [ocemp-devel] Bug in renderer with multiple layer

[Marcus v. A. <ma...@sy...>]

On, Sun Nov 05, 2006, Martin Fuzzey wrote:

> Hi Marcus,
>=20
> thank you for your very quick reply.
> Yes your fix is certainly simpler than mine and it works fine for me. I=
=20
> do have a couple of remarks though:
>=20
> If I understand it correctly the code relies on the keys() method of the=
=20
> layers dictionary returning the layer depths in increasing order. I=20
> don't think this behaviour is defined by python - from the python=20
> library reference :

Right.

> "keys and values are listed in an arbitrary order which is non-random,=20
> varies across Python implementations, and depends on the dictionary's=20
> history of insertions and deletions".
>
> Current python versions do seem to give sorted keys though (at least for=
=20
> dicts with integer keys where the hashcode is the value)

That's why I ignored the sort() issue for now. It might be better to
sort them however (better safe than sorry).

> That's why my patch stored the updates in a temporary list and sorted it=
=20
> - if you assume sorted keys the blit can be inlined in the first loop.
>=20
> Secondly my patch only updated the parts of the widgets that had changed=
=20
> rather than redrawing all of those that collide  somewhere. This was=20
> probably a case of premature optimisation (as I didn't do any=20
> performance tests first). I have now done that and for 10 widgets on a=20
> 1024x768 background:
> With your fix:  89ms
> With my patch: 42ms

The drawing and blitting code is currently not (very) optimized. I did
not made any extensive performance tests except running it on different
hardware and applying the default python inlining where possible
(filter(), [for ... ], map()).

I'll recheck that with your script and the profile module and run
several tests with the different widget types (some widgets are
incredibly slower than others, e.g. the scrolling widgets or complex
layouts like VFrame packed in HFRame packed in Table packed in VFrame
=2E..).
=20
My first guess is that your clip() approach will perform very well for
the layout cases with widgets occupying large areas, but become slower
with widgets occupying just the minimum space they need. This however
has to be proved.

> There is no significant difference between the sort() and inlined versions
>=20
> Of course whether the performance improvement is worth the increased=20
> complexity depends on your point of view, application  and hardware -=20
> the above measures were done on a AMD64 Laptop at 1.6GHz,  I'm actually=
=20
> interested in using ocempgui on less powerful hardware - I'll test on=20
> that tomorrow...

Similar to the event loop issue Regis Desgroppes brought up optional
rendering loops might be the best for different needs, if it turns out
that clip() will get slower than just blitting all for small widgets.

Regards
Marcus