bugGNU Octave - Bugs: bug #43873, large image gets cropped if...


bug #43873: large image gets cropped if width/height exceeds OpenGL limit

Submitted by:  Andreas Weber <andy1978>
Submitted on:  Tue 23 Dec 2014 08:44:15 AM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Invalid Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  3.8.2 Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 31 Mar 2015 08:34:43 PM UTC, comment #6: 

Marking as an upstream bug and closing.  This report will still be searchable and discoverable by users who come later.

Rik <rik5>
Project Administrator
Tue 31 Mar 2015 05:55:28 PM UTC, comment #5: 

I made some clarifications on this topic at this bug report:


Basically, those folks seeing the partial image are using a system in which Mesa's newer Gallium version of swrast_dri.so is used.  Here's an illustration of the missing portion:


I was able to do a crude patch that fixed the issue on a local build of Mesa, as illustrated here:


but what I did is not a valid fix, as I just commented out of the driver the lines that impose the limit and by chance I think it worked.  (Mesa's layout is to use the route of texture elements for laying out an image.)

Those folks seeing the vertical lines yet whole image have the legacy version of swrast_dri.so (same name) on their systems, as illustrated here:


There is now a patch that fixes those issues,


but whether that makes it into the driver isn't certain as the developers don't give much support to the legacy code.

BTW, I think many people with Nvidia hardware end up with the swrast software implementation, and it may be that there are some vendor-specific drivers in some cases that would override swrast.  So, those having a problem might want to look for a vendor-specific driver solution to see if there is a quick solution.

In any case, I don't think a work-around in Octave's gl-render.cc is a good idea.  That would be a lot of work just to fix things for a particular system/graphics card.  Instead, working with the Mesa developers would be more productive.  I've created a bug report for the vertical lines issue of legacy swrast here:


and a separate entry for the large image crop issue of Gallium swrast here:


Those wanting some help building Mesa can email me for details.

Dan Sebald <sebald>
Mon 29 Dec 2014 06:31:10 PM UTC, comment #4: 

I seem to have the limit specified, but the image is still produced just fine.

glxinfo | grep TEXTURE_SIZE

Rik <rik5>
Project Administrator
Mon 29 Dec 2014 05:57:41 PM UTC, comment #3: 

@Rik: what does glxinfo show as limit? On my system (with an onboard Intel GPU):

$ glxinfo -l |grep TEXTURE_SIZE

Andreas Weber <andy1978>
Project Member
Mon 29 Dec 2014 05:45:41 PM UTC, comment #2: 

I don,t get 9000 on my system onlt 8192

Doug Stewart <dastew>
Mon 29 Dec 2014 05:27:13 PM UTC, comment #1: 

This works for me, but my hardware is different.  I don't have much of a GPU so I am probably using Mesa SW emulation.  At any rate, all 9000 pixels show up.

Rik <rik5>
Project Administrator
Tue 23 Dec 2014 08:44:15 AM UTC, original submission:  

If I try to show a large image with graphics_toolkit fltk (gnuplot is fine)

image (randi (255, 10, 9000))

the width gets cropped at 8192 because GL_MAX_TEXTURE_SIZE is 8192 on my GPU. I think the best would be to split the glDrawPixels calls in this case or at least show an warning.

I made a quick change to gl-render.cc:2723 to check the maximum possible width and height but this will be shown every time a refresh is made for example moving the FLTK window or moving the mouse over the window.

opengl_renderer::draw_pixels (GLsizei width, GLsizei height, GLenum format,
                              GLenum type, const GLvoid *data)
  int max_texture_size;
  glGetIntegerv (GL_MAX_TEXTURE_SIZE, &max_texture_size);
  if (width > max_texture_size)
    warning ("opengl_renderer::draw_pixels: width exceeds maximum texture size %i of your GPU. Output will be cropped", max_texture_size);
  if (height > max_texture_size)
    warning ("opengl_renderer::draw_pixels: height exceeds maximum texture size %i of your GPU. Output will be cropped", max_texture_size);

  glDrawPixels (width, height, format, type, data);

Any ideas how we should handle this?

Andreas Weber <andy1978>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by andy1978 (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-10-22 andy1978 Dependencies- => bugs #54680 is dependent
    2015-03-31 rik5 StatusNone => Invalid
        Open/ClosedOpen => Closed
    2014-12-23 andy1978 Summarylarge image gets cropped if size/height exceeds OpenGL limit => large image gets cropped if width/height exceeds OpenGL limit

    Back to the top

    Powered by Savane 3.5