octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fltk backend fix & mouse wheel scroll factor


From: Shai Ayal
Subject: Re: fltk backend fix & mouse wheel scroll factor
Date: Tue, 29 Sep 2009 11:01:38 +0200

On Tue, Sep 29, 2009 at 10:53 AM, Michael Goffioul
<address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]