1143312 - Images longer or wider then 8192 pixels displayed incorrectly (Intel HD 4600)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Temp]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150305021524

Steps to reproduce:

Open image or HTML document with image (JPEG, PNG, GIF, BMP) longer or wider then 8192 pixels using Windows PC with Intel HD 4600 GPU (and most recent driver). If I force Firefox to use nVidia GPU or disable hardware acceleration problem doesn't occur.
Image must use at least two colors (can't be filled with just one color).


Actual results:

Starting from 8192nd pixel row or column image is black (or grey for some transparent PNGs). What's more - if both width and height are around 10 000 pixels - whole Firefox (all windows) turns black (in most cases, sometimes after refreshing tab). Some additional information can be found here: http://forums.mozillazine.org/viewtopic.php?f=23&t=2862011


Expected results:

Whole image should be displayed, and in case of images with size for example 10000x10000 Firefox windows should not turn black.

Comment 1

[Botond Ballo [:botond]]

CC'ing a few people.

Seth, is there any chance this is ImageLib-related? I'm guessing not since the problem went away when switching to an nVidia GPU, just wanted to double-check.

Comment 2

[Seth Fowler [:seth] [:s2h]]

(In reply to Botond Ballo [:botond] from comment #1)
> CC'ing a few people.
> 
> Seth, is there any chance this is ImageLib-related? I'm guessing not since
> the problem went away when switching to an nVidia GPU, just wanted to
> double-check.

I don't think so. If the GPU/driver in question can't handle texture sizes with at least one dimension larger than 8192, sounds like we need catch that situation somewhere in the graphics code and fall back appropriately.

Bas, my guess is that you'd have a better idea how we'd do that?

Comment 3

[Temp]

Did some tests with Firefox Portable. Problem appeared in Fx 32.0. In Firefox 31.0 and ESR (31.5.3) images are displayed correctly.

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to Seth Fowler [:seth] from comment #2)
> (In reply to Botond Ballo [:botond] from comment #1)
> > CC'ing a few people.
> > 
> > Seth, is there any chance this is ImageLib-related? I'm guessing not since
> > the problem went away when switching to an nVidia GPU, just wanted to
> > double-check.
> 
> I don't think so. If the GPU/driver in question can't handle texture sizes
> with at least one dimension larger than 8192, sounds like we need catch that
> situation somewhere in the graphics code and fall back appropriately.
> 
> Bas, my guess is that you'd have a better idea how we'd do that?

We should just be failing to create a SourceSurfaceD2D, and instead create a DataSourceSurface and draw that directly. The D2D backend should then ensure the correct piece is uploaded to the GPU, or in exceptional cases downsample in software, upload and then draw.

Comment 5

[Seth Fowler [:seth] [:s2h]]

(In reply to Bas Schouten (:bas.schouten) from comment #4)
> We should just be failing to create a SourceSurfaceD2D, and instead create a
> DataSourceSurface and draw that directly. The D2D backend should then ensure
> the correct piece is uploaded to the GPU, or in exceptional cases downsample
> in software, upload and then draw.

Yep. It seems like that's not what's happening right now though.

Comment 6

[Nicolas Silva [:nical]]

(In reply to Bas Schouten (:bas.schouten) from comment #4)
> We should just be failing to create a SourceSurfaceD2D, and instead create a
> DataSourceSurface and draw that directly. The D2D backend should then ensure
> the correct piece is uploaded to the GPU, or in exceptional cases downsample
> in software, upload and then draw.

We have some code on the compositor side (something called BigImage/BigImageIterator) that is specifically meant to handle this kind of issues (splits the cpu image into several gpu textures).
Perhaps we should just send the big surface to the compositor with a ShmemTextureClient instead of a D3D11 one, and let BigImageIterator do the magic?
Otherwise, if it's best to always downsample on the content side (which is appealing in term of memory consumption) rather than split on the compositor side, we should just remove the BigImage stuff from the compositor code, that'll simplify things a bit.

Comment 7

[Temp]

Seems to be fixed in Firefox 37.0.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Resolving this worksforme based on comment 7.