I corrected a run-away string (lacking a closing ") which was stopping compilation, and then checked in your cset here https://hg.savannah.gnu.org/hgweb/octave/rev/f034b29320ad.
This looks good, and now I'm in the midst of tidying up the on-screen display of markers.
|
@Rik: I attached an updated, documented, patch in which I fixed a few regressions caused by the previous one (including the garbage pixels after printing and corrupted uint16 images).
(file #46246)
|
@Rik: Yes, on-screen the manual clipping is not necessary anymore, but gl2ps still has this limitation (it doesn't handle textures and only emulates glDrawPixels). So I moved the complicated manual clipping code to gl2ps_renderer::draw_image.
The timings are the same for me too and I guess this is because the bottleneck is passing pixel data to the graphics card.
As for the ugly pixels when printing to pdf, I can confirm.
I'll look into this.
|
@Pantxo: I dumped all of the demos and compared them pre/post patch. It doesn't seem that anything is drawn incorrectly. Also, I ran 'make check' and all tests still pass.
If I understand the patch correctly, draw_image in gl-render.cc became much simpler, but draw_image in gl2ps-print.cc became much more complicated.
I would have thought using textures over gl2psDrawPixels would have been slower, but it seems not to be. I tested with a 10MB image and display times as caluclated by
were the same.
Printing to a vector format like PDF leaves some weird pixels behind, but these are cleaned up if the image is resized which forces a re-paint. It would be nice to clean that up at some point.
Sample code
|
The attached version of the patch now handles 1 pixel wide/high images.
(file #46217)
|
First regression with the patch: colorbar don't show.
|
I attached a preliminary patch that fixes the undrawn partial pixels issue on-screen (not when printing to verctor formats). Performance-wise I see no benefit but no drop down either: we would still need to cache image data. A side effect I had not foreseen is that it is possible to rotate images by changing the view, like in Matlab.
@Rik: When you find some time, can you test the patch and see if you can uncover a regression?
(file #46215)
|
I think this is a duplicate of bug #42435. In any case, I'm going to leave this one open as another reminder to work on this.
|
Since images are primitive graphics objects in Matlab and Octave, it seems that we probably need to change the rendering code in gl-render.cc. Maybe we can take some of the code from the implementation of surfaces with texturemaps and apply it to images, although that might be excessively complicated. I haven't looked.
Here is the documentation about the xdata property for images in Matlab.
It is very clear that the property specifies the centers of the pixels and that the pixels extend to either side of the center. So if I put a pixel at location 1, and then make the axis start at location 1, I really should have something drawn.
Here is slightly different code I used to test the extension of pixels in Matlab.
I've attached the result as pixel.png. It shows that the pixel does extend to 0.5 as expected.
(file #46174)
|
Yes, that doesn't look good. Using textures to project image pixels on would probably help overcome this limitation, as it would help supporting rotated text. See how using texture mapping (undocumented well hidden Octave feature :-)) on a surface object looks much better:
|
Octave "pixels" extend +/- 0.5 a grid point of their position. This leads to oddities, where part of a pixel would be outside the axes and is clipped. Matlab does not do this.
Sample code below is taken from the demo for brighten().
This leaves a small white border around the image object which is not present when using gnuplot or Matlab.
This may be a deep issue that needs to be resolved in the OpenGL renderer.
|