neg and colorfilter do not have effect on showmouse
Bug #1771341 reported by
Samuel thibault
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz |
New
|
Undecided
|
Unassigned |
Bug Description
When enabling the neg or colorfilter plugin, the showmouse artifacts are unchanged, while they should get the neg/colorfilter effect.
I'm not sure how to best fix this. AIUI, they draw their artifact directly with OpenGL, so that neg/colorfilter currently can't redirect their operations to mangle them?
description: | updated |
To post a comment you must log in.
I had a look again at how the "wrapable" mechanism works, and showmouse indeed uses the vertexbuffer and GL directly, so they can't be redirected for now.
I see three ways of fixing this bug:
- make neg and colorfilter communicate explicitly with showmouse to tell it which color filter it should apply to the colors. But the filters there are shaders, which can't easily be applied to the colors passed to stream->AddColors, so that approach would need implementations of the filters also as a C function.
- add some wrapable GLScreen: :glAddVertices interface which would allow showmouse to replace its explicit vertexbuffer and GL source code with a call to that interface. For the showmouse needs, that interface would have to comprise at least enabling blending, enabling a texture, adding vertices, texcoords and colors. And then neg and colorfilter can redirect the glAddVertices call to modify the colors. Again, it means to have also a C implementation of the filters.
- reduce the scope of the fix to only support color inversion from neg (which is what is interesting in our usecase), by making neg communicate explicitly with showmouse to tell it when it should just invert the guide color (thus a trivial color filter which can be implemented directly in showmouse).
Is there an opinion on which would be preferrable?