Comment 2 for bug 1761420

Revision history for this message
hilaire (hilaire-fernandes) wrote : Re: [Dr. Geo] [Bug 1761420] Re: Rendering time of Point Morph

Nice analysis!

Yep, the empty text morph label of point is very expensive. It was
already identified, and fixed.

Regarding your idea about partial World update, it is neat. Dedicated
methods should be implemented on the DrGeoCanvas class; it is really the
one knowing about the state of the canvas.

We can have several messages:

#updateCanvasFrequency: integer

#updateCanvas

Two additional attributes for DrGeoCanvas are needed,
updateCanvasFrequency and updateCanvasCounter

Round point are very expensive to render. The Cairo backend needs it to
be render as arc. It could be optimized in the DrGPointMoprh with a
cache Form. But I don't want to complicate its code. Now from Smalltalk
Sketch, point are rendered by default as squares, which is likely even
faster than cross.

About the point costume style, the setters need to be update
individually too. For example the #color: message needs its own #changed
message sent when the user edit its style from the GUI. How will you
write #color:pointSize:shape setter and avoid code duplication at the
same time? Writing private #color, #pointSize: #shape setters without
the changed message. I am not sure what is the best practice? In the
other hand, in the PI script, costume is initialized once per world
update cycle, when a new the point is created. I am not sure it is a
problem, is it? I have not measure its impact.

Good points!

Thanks

Hilaire

--
GNU Dr. Geo
http://drgeo.eu