Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (724)
Games in Android Showcase (216)
games submitted by our members
Games in WIP (790)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [OT] Component.repaint() & stutter  (Read 1174 times)
0 Members and 1 Guest are viewing this topic.
Offline mabraham

Junior Devvie

« Posted 2006-03-27 20:40:37 »

Apologies if this is somewhat off-topic but...

I'm developing an app which uses a GLCanvas to render some scene.  The user has certain tools they can use to draw some kind of shapes (this is all relatively basic 2-D btw).  These tools are done via mouse listeners on the canvas, and there's some pretty computation expensive code that creates these shapes (mask shapes they are, and they are rendered as textured quads btw).  Once a shape has been created or modified in the listener, it calls repaint() on the canvas to update the view.  OK so the problem I have is that while creating a new shape in the listener code takes around 10..15ms (rendering the scene itself takes about the same, depending on no of objects), view updates aren't smooth at all, and in fact the faster I drag the mouse around the worse it gets, to the point where I get virtually no view updates at all!

So why is this off-topic?  Because... it appears that repaint events are batched together and enter the event queue at low priority.  My guess is that the mouse events are flooding the queue so that none the repaint events makes it.  This has nothing to do with JOGL but I found no better place to post this, and I'm hoping someone will be able to help!

Possible solutions I've thought of so far:
  • Whenever a view parameter changes, call GLCanvas.display() directly, instead of replying on the repaint mechanism.  This is problematic with the way the app is designed.  There's so many listeners watching various different view properties that I cannot guarantee that only one of them will trigger display().  It would be very inefficient (and slow) if I get multiple updates upon a single change to one view property.
  • Move the computation from the listener code into a separate worker thread which, once the computation is finished, will invoke repaint() or display() even.  This may well work for an isolated test case, but will make the design very complex and error prone.
  • Use a JComponent instead of a canvas.  I'm not joking; obviously I don't see how that would be compatible with JOGL but: I have attached a non-GL test case that shows the difference in repaint mechanism between heavyweights and lightweights.  I'm wondering if I could employ a Swing RepaintManager maybe Huh  I dunno...
Offline Ken Russell

JGO Coder

Java games rock!

« Reply #1 - Posted 2006-03-27 21:58:38 »

Very interesting problem.

Under the circumstances I would suggest you build your own repainting mechanism on top of the display() method. Start a worker thread whose only job it is to wait for "repaint" requests on a particular GLAutoDrawable and call display() on it. If you make the requests asynchronous from when they are actually performed this will have the effect of batching them up as necessary. Here's a modified version of your test case doing this for the pure Java case; doing something similar for JOGL should actually be easier, since the RepaintHandler would deal only with GLAutoDrawables rather than having to interact with the EventQueue and do something different for the lightweight and heavyweight cases.

I'd also recommend you post your test case on the Swing and AWT board on It's surprising the behavior is so different between the two (and portably different, too -- I see the difference on Solaris/SPARC as well).
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

buddyBro (215 views)
2017-04-05 03:38:00

CopyableCougar4 (645 views)
2017-03-24 15:39:42

theagentd (639 views)
2017-03-24 15:32:08

Rule (689 views)
2017-03-19 12:43:22

Rule (665 views)
2017-03-19 12:42:17

Rule (668 views)
2017-03-19 12:36:21

theagentd (680 views)
2017-03-16 05:07:07

theagentd (613 views)
2017-03-15 22:37:06

theagentd (452 views)
2017-03-15 22:32:18

theagentd (381 views)
2017-03-15 22:31:11
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!