Avoid TexSubImage2DWithoutUnpackSubimage slowpath when using SWGL
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox91 | --- | fixed |
People
(Reporter: jrmuizel, Assigned: jrmuizel)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
OpenGL ES doesn't support extracting a subimage from the source when using glTexSubImage. The memcpy call from mozilla::gl::TexSubImage2DHelper in https://share.firefox.dev/3yn0d5C suggests we're hitting this.
The best way to avoid it is unclear.
Assignee | ||
Comment 1•3 years ago
|
||
I talked this through with Glenn and came up with the idea of using our current DataSourceSurface as a scratch buffer. Instead of drawing into the correct place in the tile's DataSourceSurface, we always draw in the top left and make sure the stride = width of the dirty rect. We should then be able to TexSubImage2D from that freshly drawn area.
Assignee | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
Updated•3 years ago
|
Comment 4•3 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)
OpenGL ES doesn't support extracting a subimage from the source when using glTexSubImage. The memcpy call from mozilla::gl::TexSubImage2DHelper in https://share.firefox.dev/3yn0d5C suggests we're hitting this.
"doesn't support efficiently extracting"?
Comment 5•3 years ago
|
||
When I applied the current D116501 on Wiko sunny2 puls(Mali-400 MP), I sometimes saw cases that part of page colors were inverted between blue and red. I tested on https://www.yahoo.co.jp/
Comment 7•3 years ago
|
||
By applying the updated patch, the color problem was addressed:) I am going to check more.
Pushed by jmuizelaar@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4521e7060665 Avoid TexSubImage ES slow path. r=jgilbert,sotaro
Comment 9•3 years ago
|
||
bugherder |
Description
•