classpath-patches
[Top][All Lists]
Advanced

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

[cp-patches] FYI: GdkGraphics optimization


From: Roman Kennke
Subject: [cp-patches] FYI: GdkGraphics optimization
Date: Wed, 14 Dec 2005 22:42:42 +0100

Hi all,

I checked in a little caching for the GdkGraphics.create() method. Let
me first explain the problem that we have with this method and then the
approach how to fix this:

In Swing painting we do a Graphics.create() for each component that is
painted, this is to protect the rest of the painting code from
irrevocable changes to the graphics context like translate(). This might
not be a problem in the code that we control but it is a problem when it
comes to user code. Also, this behaviour is specified, look into
JComponent.paintComponent(). For big GUIs you can quickly see that this
way we quickly create several hundred copies of the graphics context,
where only a couple of them is used at any time. The behaviour is O(n^2)
for n beeing the depth of the component hierarchy.

The approach for fixing this makes use of the fact that for each
Container, the children are painted independently. So in theory, we do
not need to dump one graphics context when one child is complete, only
to create a new one. This can easily be cached on the implementation
side of Graphics (in this case GdkGraphics), since at this level we have
absolute knowledge of the state of the graphics context (in contrast to
java.awt.Graphics, where a call to translate() is irrevocable). Also we
make use of the notification to dispose() after a completed painting
operation. What we do now is, when the graphics context gets
dispose()ed, we do not throw it away (call nativeDispose()), but instead
put it into the cache of it's parent (if it was created using
Graphics.create()). This is picked up in the next call to create() of
this parent and re-initialized with the correct state. nativeDispose()
is still called in finalize() to make sure that the native resources are
freed if a graphics context is not used anymore. What we get during
painting is then a chain of graphics contexts that has a maximum depth
of the depth of the component hierarchy (typically 5-15), compared to
several hundred/maybe tousand graphics contexts before.


2005-12-14  Roman Kennke  <address@hidden>

        * gnu/java/awt/peer/gtk/GdkGraphics.java
        (cached): New field.
        (parent): New field.
        (GdkGraphics(GdkGraphics)): Moved state-copy code to new method
        copyState().
        (create): Added re-use of old graphics.
        (nativeDispose): Renamed native dispose method to
nativeDispose().
        (dispose): New non-native implementation used for caching.
        (finalize): Overridden to correctly dispose unused graphics.
        (copyState): New non-native method to correctly copy the
non-native
        state.
        (nativeCopyState): Renamed native copyState method to
        nativeCopyState().
        * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkGraphics.c
        (copyState): Renamed to nativeCopyState.
        (dispose): Renamed to nativeDispose.
        * include/gnu_java_awt_peer_gtk_GdkGraphics.h
        (copyState): Renamed to nativeCopyState.
        (dispose): Renamed to nativeDispose.

/Roman

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]