Re: fltk backend fix & mouse wheel scroll factor

[Michael Goffioul]

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 <address@hidden> wrote:
> On Mon, Sep 28, 2009 at 11:42 PM, John Swensen <address@hidden> wrote:
>>
>> On Sep 28, 2009, at 3:45 PM, Shai Ayal wrote:
>>
>>> On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <address@hidden> 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
>
>