manual UI redrawing


    Aug 28 2006 | 7:38 pm
    I wrote this opengl UI object using jit.pwindow, and I'm a little in the
    dark about how to handle the redrawing the right way. With jsui, when you
    move something like a window over it, it redraws itself automatically.
    jit.pwindow doesn't do that. The only solution I know is to have a scheduler
    or qmetro redraw the ui on a fixed interval, but that feels like a big waste
    of resources, when the thing is just sitting there doing nothing.
    Is this the way regular UI elements work, or is there another / better way?
    Or maybe a way to know whether its visible or not?
    -thijs

    • Aug 28 2006 | 9:08 pm
      use a doublebuffer? I think thats the solution?
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Aug 28, 2006, at 3:38 PM, Thijs Koerselman wrote:
      > I wrote this opengl UI object using jit.pwindow, and I'm a little
      > in the dark about how to handle the redrawing the right way. With
      > jsui, when you move something like a window over it, it redraws
      > itself automatically. jit.pwindow doesn't do that. The only
      > solution I know is to have a scheduler or qmetro redraw the ui on a
      > fixed interval, but that feels like a big waste of resources, when
      > the thing is just sitting there doing nothing.
      >
      > Is this the way regular UI elements work, or is there another /
      > better way? Or maybe a way to know whether its visible or not?
      >
      > -thijs
      >
    • Aug 28 2006 | 9:24 pm
      On Aug 28, 2006, at 2:08 PM, vade wrote:
      > use a doublebuffer? I think thats the solution?
      Actually, this is only one aspect of the potential solution. This
      will let you simply swap buffers to refresh to the screen with the
      swap message to jit.gl.render, rather than redering the entire scene
      with the bang method (equivalent to the drawclients, swap message
      sequence). However, the fundamental problem Thijs is pointing out is
      that jit.pwindow does not expose any way to know if the jit.pwindow
      visible region has been invalidated and needs to be swapped.
      jit.pwindow works fine this way when it doesn't own an OpenGL
      context, with jitter matrices, as it knows when it has been
      invalidated and when to refresh, copying the RAM backing buffer to
      the screen (@onscreen 0). We can add something to expose this via
      jit.pwindow in the future, but for now, you'll need to use some other
      technique to work around this limitation.
      -Joshua
    • Aug 28 2006 | 10:42 pm
      On 8/28/06, Joshua Kit Clayton wrote:
      >
      >
      > On Aug 28, 2006, at 2:08 PM, vade wrote:
      >
      > > use a doublebuffer? I think thats the solution?
      >
      > Actually, this is only one aspect of the potential solution. This
      > will let you simply swap buffers to refresh to the screen with the
      > swap message to jit.gl.render, rather than redering the entire scene
      > with the bang method (equivalent to the drawclients, swap message
      > sequence).
      I always assumed that you can only swap once, and if you do it twice you get
      a blank buffer, but come to think of think of it.... as long as it's not
      erased you can keep swapping. makes perfect sense:-)
      jit.pwindow works fine this way when it doesn't own an OpenGL
      > context, with jitter matrices, as it knows when it has been
      > invalidated and when to refresh, copying the RAM backing buffer to
      > the screen (@onscreen 0). We can add something to expose this via
      > jit.pwindow in the future, but for now, you'll need to use some other
      > technique to work around this limitation.
      The only workaround I can think of is to render the ui only if it's the
      front patcher window. That won't work for pluggo I suspect, but it will take
      a while before I get to that anyway. I would certainly appreciate it if this
      feature can be added in the future, because I plan on making a lot more UI
      stuff with jit.pwindow.
      speaking of redrawing... I have a timeline walking across on top of
      everything else. To prevent the ui from re-rendering, I cache the context to
      a texture, and draw the texture on a plane with the timeline over it. Works
      fine, but I have a feeling there is a better way. If so please enlighten me.
      Something similar to copypixels in jsui maybe?
      cheers, -thijs
    • Aug 29 2006 | 12:01 am
      On Aug 28, 2006, at 3:42 PM, Thijs Koerselman wrote:
      > speaking of redrawing... I have a timeline walking across on top of
      > everything else. To prevent the ui from re-rendering, I cache the
      > context to a texture, and draw the texture on a plane with the
      > timeline over it. Works fine, but I have a feeling there is a
      > better way. If so please enlighten me. Something similar to
      > copypixels in jsui maybe?
      Rendering to a texture and re-using the texture is the best way to do
      this in Jitter. The copypixels method is only better in JSUI since it
      is in software. On the HW, the only way we expose you to cache GPU
      pixel resources is through textures.
      -Joshua
    • Aug 29 2006 | 12:37 am
      On 8/29/06, Joshua Kit Clayton wrote:
      >
      > Rendering to a texture and re-using the texture is the best way to do
      > this in Jitter. The copypixels method is only better in JSUI since it
      > is in software. On the HW, the only way we expose you to cache GPU
      > pixel resources is through textures.
      ok that's fine, just checking. The swapping is working out great. I'm
      updating only once every 500ms (in idle state) so there is no noticeable cpu
      load yet. I still have to think about the timeline drawing but its looking
      good so far. Thanks a lot.
      -thijs