Mir gets textures/buffers confused when running both scroll and flicker demos
Bug #1263592 reported by
Daniel van Vugt
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mir |
Fix Released
|
High
|
Daniel van Vugt | ||
| mir (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bug Description
Mir gets textures/buffers confused when running both scroll and flicker demos
1. Start mir_demo_
2. sudo bin/mir_
3. Alt+Tab between the two clients
Expected: Both scroll and flicker demos to be visible.
Observed: When the scroll demo is focused, the flicker surface becomes a mirror of the scroll surface. I only see two scrolls and no flicker.
Related branches
lp:~vanvugt/mir/texture-cache
- PS Jenkins bot (community): Approve (continuous-integration)
- Alexandros Frantzis (community): Approve
- Alan Griffiths: Approve
- Kevin DuBois (community): Needs Information
- Robert Carr (community): Approve
- Daniel van Vugt: Pending requested
-
Diff: 549 lines (+232/-62)11 files modifiedinclude/test/mir_test_doubles/mock_surface_renderer.h (+1/-0)
src/server/compositor/default_display_buffer_compositor.cpp (+1/-0)
src/server/compositor/gl_renderer.cpp (+46/-16)
src/server/compositor/gl_renderer.h (+17/-1)
src/server/compositor/renderer.h (+2/-0)
tests/acceptance-tests/test_server_shutdown.cpp (+3/-0)
tests/integration-tests/test_session.cpp (+3/-0)
tests/integration-tests/test_surface_first_frame_sync.cpp (+4/-0)
tests/mir_test_framework/stubbed_server_configuration.cpp (+4/-0)
tests/unit-tests/compositor/test_default_display_buffer_compositor.cpp (+9/-0)
tests/unit-tests/compositor/test_gl_renderer.cpp (+142/-45)
| summary: |
- Mir gets buffers confused when running both scroll and flicker demos + Mir gets textures/buffers confused when running both scroll and flicker + demos |
| description: | updated |
Revision history for this message
| Daniel van Vugt (vanvugt) wrote | #1 |
| Changed in mir: | |
| assignee: | nobody → Daniel van Vugt (vanvugt) |
| Changed in mir: | |
| status: | Triaged → In Progress |
Revision history for this message
| PS Jenkins bot (ps-jenkins) wrote | #2 |
| Changed in mir: | |
| status: | In Progress → Fix Committed |
| Changed in mir: | |
| status: | Fix Committed → Fix Released |
Revision history for this message
| Daniel van Vugt (vanvugt) wrote | #3 |
| Changed in mir (Ubuntu): | |
| importance: | Undecided → High |
| status: | New → Fix Released |
To post a comment you must log in.
The problem seems to be when a hardware surface is in front of a software surface of the same dimensions. So we call:
1. Software surface: glTexImage2D
2. Hardware surface: glEGLImageTarge
GL seems to be getting confused as we reuse a single texture ID for all surfaces. And in the above scenario it only uses the second upload for both surfaces.
So it could be a bug in Mesa's glEGLImageTarge