Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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 1441 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  

EgonOlsen (59 views)
2018-06-10 19:43:48

EgonOlsen (42 views)
2018-06-10 19:43:44

EgonOlsen (61 views)
2018-06-10 19:43:20

DesertCoockie (240 views)
2018-05-13 18:23:11

nelsongames (142 views)
2018-04-24 18:15:36

nelsongames (141 views)
2018-04-24 18:14:32

ivj94 (883 views)
2018-03-24 14:47:39

ivj94 (144 views)
2018-03-24 14:46:31

ivj94 (795 views)
2018-03-24 14:43:53

Solater (159 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

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 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!