fltk backend fix & mouse wheel scroll factor

[shaiay]

Hi

The attached changset fixes a bug which did not show the zoom box.
Also added a function to enable the user to control the zoom factor
when using mouse wheel zoom.

I think that with this changeset, the fltk_backend is quite usable as
a viewer to the gl-renderer. I am open to feature requests.

Shai

[Søren Hauberg]

søn, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
> The attached changset fixes a bug which did not show the zoom box.
> Also added a function to enable the user to control the zoom factor
> when using mouse wheel zoom.
>
> I think that with this changeset, the fltk_backend is quite usable as
> a viewer to the gl-renderer.

I think this is really nice. With this changeset, the FLTK backend is
very nice to use for 2D plots (much better than both gnuplot and
matlab).

>  I am open to feature requests.

Well, then I'm gonna file a request :-) It would be great to have better
support for navigating in 3D. Basically, I think dragging the mouse
should make 3D plots rotate around some point (center of mass?), while
scrolling should change the distance between the camera and said point.

Søren

[Søren Hauberg]

søn, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
> The attached changset fixes a bug which did not show the zoom box.
> Also added a function to enable the user to control the zoom factor
> when using mouse wheel zoom.
>
> I think that with this changeset, the fltk_backend is quite usable as
> a viewer to the gl-renderer. I am open to feature requests.

I've just stumbled upon a bug, that may or may not be related to this
changeset. If I

  a) click somewhere on a plot with the right mouse button without
     releasing it,

  b) move the mouse somewhere else inside the plot, and

  c) release the right button,

then nothing happens, except from then on, I cannot zoom any more using
the mouse wheel.

Søren

[shaiay]

On Sun, Sep 27, 2009 at 5:40 PM, Søren Hauberg <soren@...> wrote:

> søn, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
>> The attached changset fixes a bug which did not show the zoom box.
>> Also added a function to enable the user to control the zoom factor
>> when using mouse wheel zoom.
>>
>> I think that with this changeset, the fltk_backend is quite usable as
>> a viewer to the gl-renderer. I am open to feature requests.
>
> I've just stumbled upon a bug, that may or may not be related to this
> changeset. If I
>
>  a) click somewhere on a plot with the right mouse button without
>     releasing it,
>
>  b) move the mouse somewhere else inside the plot, and
>
>  c) release the right button,
>
> then nothing happens, except from then on, I cannot zoom any more using
> the mouse wheel.

Strange. When I do a right drag inside a plot I get a zoom-frame. When
I release the right button the plot zooms accordingly, and the scroll
wheel works all of the time.
What system are you running on, and if you have it installed, what is
the output of
glxinfo | grep render

Shai

[Søren Hauberg]

søn, 27 09 2009 kl. 18:22 +0300, skrev Shai Ayal:
> Strange. When I do a right drag inside a plot I get a zoom-frame. When
> I release the right button the plot zooms accordingly, and the scroll
> wheel works all of the time.
> What system are you running on, and if you have it installed, what is
> the output of
> glxinfo | grep render

This is on Ubuntu 9.04 with an Intel graphics card. The glxinfo output
is

        No kernel support for execution fencing, disabling texture
        tiling
        direct rendering: Yes
        OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express
        Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2

Intel graphics cards are known to have some issues on this version of
Ubuntu, so it just might be a driver issue. I would, however, find that
somewhat weird since the FLTK backend in general works quite well.

Søren

[shaiay]

On Sun, Sep 27, 2009 at 6:30 PM, Søren Hauberg <soren@...> wrote:

> søn, 27 09 2009 kl. 18:22 +0300, skrev Shai Ayal:
>> Strange. When I do a right drag inside a plot I get a zoom-frame. When
>> I release the right button the plot zooms accordingly, and the scroll
>> wheel works all of the time.
>> What system are you running on, and if you have it installed, what is
>> the output of
>> glxinfo | grep render
>
> This is on Ubuntu 9.04 with an Intel graphics card. The glxinfo output
> is
>
>        No kernel support for execution fencing, disabling texture
>        tiling
>        direct rendering: Yes
>        OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express
>        Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2
>
> Intel graphics cards are known to have some issues on this version of
> Ubuntu, so it just might be a driver issue. I would, however, find that
> somewhat weird since the FLTK backend in general works quite well.

I think this IS an intel issue. I have an intel card at work, so I can
try it there, but it'll have to wait until tuesday.
If you can't bear the suspense, you can try to run X w/o DRI and see
what happens.

Shai

[John Swensen]

On Sep 27, 2009, at 4:16 AM, Søren Hauberg wrote:

> søn, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
>> The attached changset fixes a bug which did not show the zoom box.
>> Also added a function to enable the user to control the zoom factor
>> when using mouse wheel zoom.
>>
>> I think that with this changeset, the fltk_backend is quite usable as
>> a viewer to the gl-renderer.
>
> I think this is really nice. With this changeset, the FLTK backend is
> very nice to use for 2D plots (much better than both gnuplot and
> matlab).
>
>> I am open to feature requests.
>
> Well, then I'm gonna file a request :-) It would be great to have  
> better
> support for navigating in 3D. Basically, I think dragging the mouse
> should make 3D plots rotate around some point (center of mass?), while
> scrolling should change the distance between the camera and said  
> point.

I have always been a big fan of how the 3D solid modeling programs  
(e.g. ProE and SolidWorks) do their 3D navigation.  The way I see it  
working with Octave is as follows.  There would be 4 different "views"  
available from the plotting window.  Views 1-3 would be associated  
with looking at the plot along each of the cardinal axes.  The four  
would be the "working view".  The user has 2 options regarding how the  
object rotations (or the camera rotates about the object).  The first  
is based on a center of mass idea as you indicated.  This works great  
for solid modeling, since objects have a clear center of mass, but for  
plotting it is more difficult since it becomes not obvious how to  
weight things like lines.  A cloud of points would be easiest to  
implement this behavior.  The second way that solid modeling programs  
work is to allow you to set the center of rotation by switching to the  
3 orthogonal views to set the point of rotation.  Then, you can return  
to the "working view" and rotate and pan as would be expected.  This  
would be harder to implement, and I'm not exactly sure how this meshes  
with how the property tree manages camera position, but I think it  
would help keep from grumbling and muttering unspeakable things every  
time I try to rotate and pan in both Matlab and Octave.

John Swensen

[shaiay]

On Mon, Sep 28, 2009 at 1:05 AM, John Swensen <jpswensen@...> wrote:

>
> On Sep 27, 2009, at 4:16 AM, Søren Hauberg wrote:
>
>> søn, 27 09 2009 kl. 09:12 +0300, skrev Shai Ayal:
>>>
>>> The attached changset fixes a bug which did not show the zoom box.
>>> Also added a function to enable the user to control the zoom factor
>>> when using mouse wheel zoom.
>>>
>>> I think that with this changeset, the fltk_backend is quite usable as
>>> a viewer to the gl-renderer.
>>
>> I think this is really nice. With this changeset, the FLTK backend is
>> very nice to use for 2D plots (much better than both gnuplot and
>> matlab).
>>
>>> I am open to feature requests.
>>
>> Well, then I'm gonna file a request :-) It would be great to have better
>> support for navigating in 3D. Basically, I think dragging the mouse
>> should make 3D plots rotate around some point (center of mass?), while
>> scrolling should change the distance between the camera and said point.
>
> I have always been a big fan of how the 3D solid modeling programs (e.g.
> ProE and SolidWorks) do their 3D navigation.  The way I see it working with
> Octave is as follows.  There would be 4 different "views" available from the
> plotting window.  Views 1-3 would be associated with looking at the plot
> along each of the cardinal axes.  The four would be the "working view".  The
> user has 2 options regarding how the object rotations (or the camera rotates
> about the object).  The first is based on a center of mass idea as you
> indicated.  This works great for solid modeling, since objects have a clear
> center of mass, but for plotting it is more difficult since it becomes not
> obvious how to weight things like lines.  A cloud of points would be easiest
> to implement this behavior.  The second way that solid modeling programs
> work is to allow you to set the center of rotation by switching to the 3
> orthogonal views to set the point of rotation.  Then, you can return to the
> "working view" and rotate and pan as would be expected.  This would be
> harder to implement, and I'm not exactly sure how this meshes with how the
> property tree manages camera position, but I think it would help keep from
> grumbling and muttering unspeakable things every time I try to rotate and
> pan in both Matlab and Octave.

These are both good suggestions.
1. for the center of mass rotation -- I am not sure but I think this
should be implemented in octave-core level, rather than in the
backend. This would also add some computational burden. I could
implement the degenerate case of rotating about the center of view
(i.e. the middle of the axes)
2. the solid model way - this is purely backend stuff, and actually
might be easier to implement. Do you have more details -- how exactly
do you select the point in the orthogonal views?

Shai

[John W. Eaton-3]

On 27-Sep-2009, Shai Ayal wrote:

| The attached changset fixes a bug which did not show the zoom box.
| Also added a function to enable the user to control the zoom factor
| when using mouse wheel zoom.
|
| I think that with this changeset, the fltk_backend is quite usable as
| a viewer to the gl-renderer.

I applied it.  Zooming seems to work well for me now with either the
scroll wheel or the click and drag method.

| I am open to feature requests.

Just about zooming/rotating issues, or other things?  :-)

If we just had images working, then the fltk backend might be able to
run all the demos...

jwe

[shaiay]

On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe@...> wrote:

> On 27-Sep-2009, Shai Ayal wrote:
>
> | The attached changset fixes a bug which did not show the zoom box.
> | Also added a function to enable the user to control the zoom factor
> | when using mouse wheel zoom.
> |
> | I think that with this changeset, the fltk_backend is quite usable as
> | a viewer to the gl-renderer.
>
> I applied it.  Zooming seems to work well for me now with either the
> scroll wheel or the click and drag method.
>
> | I am open to feature requests.
>
> Just about zooming/rotating issues, or other things?  :-)
>
> If we just had images working, then the fltk backend might be able to
> run all the demos...

My problem right now is that I have only very short timeslots (~1
hour) for this, so I try to do small simple stuff. I'll have a look at
the image code (probably copy from jhandles as usual..) and see if it
fits the timeslot.

Shai

[John Swensen]

On Sep 28, 2009, at 3:45 PM, Shai Ayal wrote:

> On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe@...> wrote:
>> On 27-Sep-2009, Shai Ayal wrote:
>>
>> | The attached changset fixes a bug which did not show the zoom box.
>> | Also added a function to enable the user to control the zoom factor
>> | when using mouse wheel zoom.
>> |
>> | I think that with this changeset, the fltk_backend is quite  
>> usable as
>> | a viewer to the gl-renderer.
>>
>> I applied it.  Zooming seems to work well for me now with either the
>> scroll wheel or the click and drag method.
>>
>> | I am open to feature requests.
>>
>> Just about zooming/rotating issues, or other things?  :-)
>>
>> If we just had images working, then the fltk backend might be able to
>> run all the demos...
>
> My problem right now is that I have only very short timeslots (~1
> hour) for this, so I try to do small simple stuff. I'll have a look at
> the image code (probably copy from jhandles as usual..) and see if it
> fits the timeslot.
>
> Shai
>

Is implementing the images in the gl renderer and harder than making a  
texture with the image on it as a very small negative z-depth, so that  
things plotted on top of it show up?  If that is the case, then I may  
be able to take look at this.

John

[shaiay]

On Mon, Sep 28, 2009 at 11:42 PM, John Swensen <jpswensen@...> wrote:

>
> On Sep 28, 2009, at 3:45 PM, Shai Ayal wrote:
>
>> On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe@...> wrote:
>>>
>>> On 27-Sep-2009, Shai Ayal wrote:
>>>
>>> | The attached changset fixes a bug which did not show the zoom box.
>>> | Also added a function to enable the user to control the zoom factor
>>> | when using mouse wheel zoom.
>>> |
>>> | I think that with this changeset, the fltk_backend is quite usable as
>>> | a viewer to the gl-renderer.
>>>
>>> I applied it.  Zooming seems to work well for me now with either the
>>> scroll wheel or the click and drag method.
>>>
>>> | I am open to feature requests.
>>>
>>> Just about zooming/rotating issues, or other things?  :-)
>>>
>>> If we just had images working, then the fltk backend might be able to
>>> run all the demos...
>>
>> My problem right now is that I have only very short timeslots (~1
>> hour) for this, so I try to do small simple stuff. I'll have a look at
>> the image code (probably copy from jhandles as usual..) and see if it
>> fits the timeslot.
>>
>> Shai
>>
>
> Is implementing the images in the gl renderer and harder than making a
> texture with the image on it as a very small negative z-depth, so that
> things plotted on top of it show up?  If that is the case, then I may be
> able to take look at this.

That should do the trick, and there is even a texture helper class
already in gl-render.cc
However there might be a complication if the image is large (10
megapixel images are not uncommon) - I am not sure but there will be
limits to texture sizes. Maybe using a gl bitmap might be better? I
have not studied this yet, so I'm unsure

Shai

[Michael Goffioul-2]

The way I did it in JHandles is by using a texture and drawing a filled
rectangle in the middle of the plot box (z == (zmin+zmax)/2). The
low-level code is already present in octave; for instance you can
already apply a texture to a surface object (did you know that?).

Adding image support to octave is something that is in my mind for
a couple of months now. But besides lack of time (I'm busy with
another personal project), the main thing I'd like to implement before
that is a good, efficient and generic cache system in the graphics
code. Indeed, as converting the image data into something that is
usable in OpenGL and loading it into video memory is a time-consuming
process, you'd want to cache the result (texture index) for re-use on
the next redraw (that's done in JHandles). The main problem I still
have to resolve is where to store the cache objects (octave, renderer,
backend...) and the process of invalidating the cache. For instance,
concerning the latter, changing the figure colormap might invalidate
images cached texture if they use indexed colors.

Now, the current code in octave uses regular OpenGL textures, but
this approach has several limitations:
- the texture needs to be square and a power of 2, which can be very
  inefficient for non-square images, or with a size that is 2^n+1 pixel
  wide; in that case, detecting non-square texture support in the
  OpenGL engine and using it is probably a better approach
- textures are limited in size: for instance on my laptop the maximum
  texture size is 2048*2048; decomposing the main texture into several
  subtextures can work around the problem, but that's not trivial

Michael.


On Tue, Sep 29, 2009 at 5:30 AM, Shai Ayal <shaiay@...> wrote:

> On Mon, Sep 28, 2009 at 11:42 PM, John Swensen <jpswensen@...> wrote:
>>
>> On Sep 28, 2009, at 3:45 PM, Shai Ayal wrote:
>>
>>> On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe@...> wrote:
>>>>
>>>> On 27-Sep-2009, Shai Ayal wrote:
>>>>
>>>> | The attached changset fixes a bug which did not show the zoom box.
>>>> | Also added a function to enable the user to control the zoom factor
>>>> | when using mouse wheel zoom.
>>>> |
>>>> | I think that with this changeset, the fltk_backend is quite usable as
>>>> | a viewer to the gl-renderer.
>>>>
>>>> I applied it.  Zooming seems to work well for me now with either the
>>>> scroll wheel or the click and drag method.
>>>>
>>>> | I am open to feature requests.
>>>>
>>>> Just about zooming/rotating issues, or other things?  :-)
>>>>
>>>> If we just had images working, then the fltk backend might be able to
>>>> run all the demos...
>>>
>>> My problem right now is that I have only very short timeslots (~1
>>> hour) for this, so I try to do small simple stuff. I'll have a look at
>>> the image code (probably copy from jhandles as usual..) and see if it
>>> fits the timeslot.
>>>
>>> Shai
>>>
>>
>> Is implementing the images in the gl renderer and harder than making a
>> texture with the image on it as a very small negative z-depth, so that
>> things plotted on top of it show up?  If that is the case, then I may be
>> able to take look at this.
>
> That should do the trick, and there is even a texture helper class
> already in gl-render.cc
> However there might be a complication if the image is large (10
> megapixel images are not uncommon) - I am not sure but there will be
> limits to texture sizes. Maybe using a gl bitmap might be better? I
> have not studied this yet, so I'm unsure
>
> Shai
>
>

[shaiay]

On Tue, Sep 29, 2009 at 10:53 AM, Michael Goffioul
<michael.goffioul@...> wrote:

> The way I did it in JHandles is by using a texture and drawing a filled
> rectangle in the middle of the plot box (z == (zmin+zmax)/2). The
> low-level code is already present in octave; for instance you can
> already apply a texture to a surface object (did you know that?).
>
> Adding image support to octave is something that is in my mind for
> a couple of months now. But besides lack of time (I'm busy with
> another personal project), the main thing I'd like to implement before
> that is a good, efficient and generic cache system in the graphics
> code. Indeed, as converting the image data into something that is
> usable in OpenGL and loading it into video memory is a time-consuming
> process, you'd want to cache the result (texture index) for re-use on
> the next redraw (that's done in JHandles). The main problem I still
> have to resolve is where to store the cache objects (octave, renderer,
> backend...) and the process of invalidating the cache. For instance,
> concerning the latter, changing the figure colormap might invalidate
> images cached texture if they use indexed colors.
>
> Now, the current code in octave uses regular OpenGL textures, but
> this approach has several limitations:
> - the texture needs to be square and a power of 2, which can be very
>  inefficient for non-square images, or with a size that is 2^n+1 pixel
>  wide; in that case, detecting non-square texture support in the
>  OpenGL engine and using it is probably a better approach
> - textures are limited in size: for instance on my laptop the maximum
>  texture size is 2048*2048; decomposing the main texture into several
>  subtextures can work around the problem, but that's not trivial

What would you say to using opengl bitmaps? As far as a\I managed to
read up on them this morning thy don't have a size limit, and they can
be scaled. They are limited -- they do not participate in all they
perspective and 3D stuff, but I think images are meant to be this way
-- if you want something more sophisticated you can use a textured
surface, or convert the image to a surface.

Shai

[Michael Goffioul-2]

On Tue, Sep 29, 2009 at 10:01 AM, Shai Ayal <shaiay@...> wrote:
> What would you say to using opengl bitmaps? As far as a\I managed to
> read up on them this morning thy don't have a size limit, and they can
> be scaled. They are limited -- they do not participate in all they
> perspective and 3D stuff, but I think images are meant to be this way
> -- if you want something more sophisticated you can use a textured
> surface, or convert the image to a surface.

I see 2 problems with using bitmaps:
- they are not 3D
- you have a 1-to-1 pixel mapping between the bitmap and the screen,
  which is not what Matlab is doing; for instance a colorbar is just a
  c x 1 image object rendered in a m x n box (m>c, n>>1); you can do
  that seamlessly with textures

Moreover, texture rendering is much faster than using bitmaps.

[shaiay]

On Tue, Sep 29, 2009 at 11:12 AM, Michael Goffioul
<michael.goffioul@...> wrote:
> I see 2 problems with using bitmaps:
> - they are not 3D
But images are not 3D either right?

> - you have a 1-to-1 pixel mapping between the bitmap and the screen,
>  which is not what Matlab is doing; for instance a colorbar is just a
>  c x 1 image object rendered in a m x n box (m>c, n>>1); you can do
>  that seamlessly with textures
I thought so too, but I found out this morning about glPixelZoom which
will scale the bitmap:
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/pixelzoom.html

> Moreover, texture rendering is much faster than using bitmaps
I suppose this will depend on the hardware. I would think that at
least for software only implementations like mesa, bitmap would be
faster since less processing is needed before drawing (e.g. no
transformation matrix)

Shai

[Michael Goffioul-2]

On Tue, Sep 29, 2009 at 10:22 AM, Shai Ayal <shaiay@...> wrote:
> On Tue, Sep 29, 2009 at 11:12 AM, Michael Goffioul
> <michael.goffioul@...> wrote:
>> I see 2 problems with using bitmaps:
>> - they are not 3D
> But images are not 3D either right?

What I meant is that you won't be able to render images in
3D plot. You could still then use surface objects, but the
limitations I mentioned are still valid.

>> - you have a 1-to-1 pixel mapping between the bitmap and the screen,
>>  which is not what Matlab is doing; for instance a colorbar is just a
>>  c x 1 image object rendered in a m x n box (m>c, n>>1); you can do
>>  that seamlessly with textures
> I thought so too, but I found out this morning about glPixelZoom which
> will scale the bitmap:
> http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/pixelzoom.html

That might help indeed.

>> Moreover, texture rendering is much faster than using bitmaps
> I suppose this will depend on the hardware. I would think that at
> least for software only implementations like mesa, bitmap would be
> faster since less processing is needed before drawing (e.g. no
> transformation matrix)

I'm not sure that it'll depend so much on the hardware. The bottleneck
will be the process of uploading the bitmap into the video memory, that
you'll have to do each time you want to draw the image (I don't see
any way of caching that). And to be honest, I have the impression that
graphics card are optimized for texture handling, not for direct buffer
access.

Anyway, if you want to give it try, please do. It's better than nothing.

Michael.

[shaiay]

On Sun, Sep 27, 2009 at 5:58 PM, Shai Ayal <shaiay@...> wrote:

> On Sun, Sep 27, 2009 at 6:30 PM, Søren Hauberg <soren@...> wrote:
>> søn, 27 09 2009 kl. 18:22 +0300, skrev Shai Ayal:
>>> Strange. When I do a right drag inside a plot I get a zoom-frame. When
>>> I release the right button the plot zooms accordingly, and the scroll
>>> wheel works all of the time.
>>> What system are you running on, and if you have it installed, what is
>>> the output of
>>> glxinfo | grep render
>>
>> This is on Ubuntu 9.04 with an Intel graphics card. The glxinfo output
>> is
>>
>>        No kernel support for execution fencing, disabling texture
>>        tiling
>>        direct rendering: Yes
>>        OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express
>>        Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2
>>
>> Intel graphics cards are known to have some issues on this version of
>> Ubuntu, so it just might be a driver issue. I would, however, find that
>> somewhat weird since the FLTK backend in general works quite well.
>
> I think this IS an intel issue. I have an intel card at work, so I can
> try it there, but it'll have to wait until tuesday.
> If you can't bear the suspense, you can try to run X w/o DRI and see
> what happens.

Well, I tried to try it with an intel card, but X on my intel computer
would not run! I had to revert to vesa drivers, and everything looks
OK.
I think this is an issue with the overlays, like I use to draw the
zoom rubber-band. I might try to draw it normally, not in an overlay
(maybe adding a cool blue transparent rectangle like in the gnuplot
wxt terminal).

Shai

[Søren Hauberg]

tir, 29 09 2009 kl. 13:38 +0200, skrev Shai Ayal:
> I think this is an issue with the overlays, like I use to draw the
> zoom rubber-band. I might try to draw it normally, not in an overlay
> (maybe adding a cool blue transparent rectangle like in the gnuplot
> wxt terminal).

I don't see any rubber-band during drag-zoom, so this sounds like part
of the problem.

Søren

[shaiay]

On Tue, Sep 29, 2009 at 1:40 PM, Søren Hauberg <soren@...> wrote:
> tir, 29 09 2009 kl. 13:38 +0200, skrev Shai Ayal:
>> I think this is an issue with the overlays, like I use to draw the
>> zoom rubber-band. I might try to draw it normally, not in an overlay
>> (maybe adding a cool blue transparent rectangle like in the gnuplot
>> wxt terminal).
>
> I don't see any rubber-band during drag-zoom, so this sounds like part
> of the problem.
>
Do the problems start when you try to zoom with the right button, or
are they always there?
Shai