You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In may endeavor to increase the performance of Draw2d drawing of larger graphs I finally came a step forward and found out one of the major reasons why Draw2d is generating a lot of garbage during repaints. In the screenshot below you can see a memory profile after I moved the mouse across a larger graph. The top 7 objects are 97% of the objects created. From this 904k objects app. 80% are originating from one single Draw 2d feature: Setting and restoring clipping rectangles
That means every-time a figure is drawn it first pushes the GC state, sets a clip rectangle and after it is finished drawing it pushes the state. In all three stages clipping is updated in GC. After checking with SWT's windows and gtk implementation I saw that this are very heavy functions.
My first intuition was to reduce the memory burden on SWT's side. However after a quick recap of the GTK Cairo API I noticed that there is not really a sensible solution for GTK Cario.
So this brings me now back to Draw2d. The only solution that I would see now is to reduce the number of setClipping calls. This could for example be done by removing the clipping state from the SWT Graphics' state and remove the setClipping calls from the different paint methods in Figure.
However this would change for some of our users the drawing behavior. Namely for those who are relying on clipping for painting their figures. So I feel a bit in a deadlock.
Removing the clipping would definitely break our code.
I think for many use cases the overhead of clipping is no problem, so perhaps the best approach would be do find a solution for use cases like yours, where the graphs are very large.
A simple solution could be to make clipping optional by just guarding it in the drawing functions.
Could you provide some example code for this discussion?
In may endeavor to increase the performance of Draw2d drawing of larger graphs I finally came a step forward and found out one of the major reasons why Draw2d is generating a lot of garbage during repaints. In the screenshot below you can see a memory profile after I moved the mouse across a larger graph. The top 7 objects are 97% of the objects created. From this 904k objects app. 80% are originating from one single Draw 2d feature: Setting and restoring clipping rectangles
That means every-time a figure is drawn it first pushes the GC state, sets a clip rectangle and after it is finished drawing it pushes the state. In all three stages clipping is updated in GC. After checking with SWT's windows and gtk implementation I saw that this are very heavy functions.
My first intuition was to reduce the memory burden on SWT's side. However after a quick recap of the GTK Cairo API I noticed that there is not really a sensible solution for GTK Cario.
So this brings me now back to Draw2d. The only solution that I would see now is to reduce the number of setClipping calls. This could for example be done by removing the clipping state from the SWT Graphics' state and remove the setClipping calls from the different paint methods in
Figure
.However this would change for some of our users the drawing behavior. Namely for those who are relying on clipping for painting their figures. So I feel a bit in a deadlock.
I hope by writing this down here someone has an idea what to do. I was specifically hoping for @pcdavid, @Phillipus, @Destrolaric @vogella, or @ptziegler.
The text was updated successfully, but these errors were encountered: