For the record, I wouldn't mind if someone who is in a better position to test it commandeered this revision. I think I mentioned that on irc.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Dec 12 2019
- Rebase on master
- Limit the line length to 100 characters.
Dec 11 2019
Nov 30 2019
In D25611#569457, @zzag wrote:In D25611#569453, @fredrik wrote:The decoration parts should already be padded. The commit message in the commit that introduced the atlas (6ad4c775d7840e64a07e27d6719a3ea7c3ee5eb8) even says so:
"The images are separated by a row of transparent texels to minimize artifacts from oversampling."Yes, it does and that's the problem since the transparent texels contribute to the final output value. Am I missing something?
Nov 29 2019
The decoration parts should already be padded. The commit message in the commit that introduced the atlas (6ad4c775d7840e64a07e27d6719a3ea7c3ee5eb8) even says so:
"The images are separated by a row of transparent texels to minimize artifacts from oversampling."
Nov 26 2019
Rebase on master.
Oct 7 2019
Sep 22 2019
Use a fence to ensure that all rendering is complete before swapping buffers.
Sep 21 2019
In D23881#535167, @romangg wrote:In D23881#529634, @ekurzinger wrote:Also, apart from the above two comments, any thoughts to how this relates to Roman's pending re-work of a lot of the GLX code https://phabricator.kde.org/D23105?
@fredrik: I would be interested in this as well. This change allows to schedule buffer swaps like we do with swap events at some point before the vblank and then get an event through second thread when the thread is unblocked again i.e. when the swap has been completed, right? This should also work with my rework patches only providing a single path with an event after swap (or a fallback timer if such an event is not available on the hardware).
Sep 11 2019
Sep 7 2019
Only disable sRGB configurations on LLVMpipe when the default depth is 16.
Aug 28 2019
This code doesn't actually have anything to do with triple-buffering. Its sole function is to detect whether glXSwapBuffers() blocks; the (incorrect) assumption being that if it doesn't, then the driver uses triple-buffering.
But this information is only used to decide whether to call glXSwapBuffers() in prepareRenderingFrame() or endRenderingFrame(). KWin doesn't try to render more than one frame per swap interval regardless.
Aug 23 2019
In D23105#514634, @romangg wrote:In D23105#514201, @fredrik wrote:In D23105#512099, @romangg wrote:In D23105#511957, @fredrik wrote:NVIDIA doesn't support the OML extensions. They can't be implemented efficiently on their hardware IIRC.
[...]That's good to know. Thanks! I believe we can let in some of these extensions again without increasing the complexity too much as long as the SGI ones is ignored and we have no manual control of vsync. The complexity in the old code came mostly from that.
That would leave the user without a way to override the driver's default vsync setting.
I want KWin to run v-synced always. I don't think it makes sense to make this configurable by the user. It's the default in our Wayland session and on X11 the compositor should always run v-synced as well. Or is there a valid use case for running it async in your opinion?
Aug 19 2019
By the way, you are partially duplicating work already done in this branch:
https://cgit.kde.org/kwin.git/log/?h=fredrik/swap-event-wip2
In D23105#512099, @romangg wrote:In D23105#511957, @fredrik wrote:NVIDIA doesn't support the OML extensions. They can't be implemented efficiently on their hardware IIRC.
[...]That's good to know. Thanks! I believe we can let in some of these extensions again without increasing the complexity too much as long as the SGI ones is ignored and we have no manual control of vsync. The complexity in the old code came mostly from that.
Aug 14 2019
NVIDIA doesn't support the OML extensions. They can't be implemented efficiently on their hardware IIRC.
Jul 21 2019
Jul 9 2019
Jul 8 2019
Jul 2 2019
In D22153#489729, @zzag wrote:... also please change blur: to [effects/blur] in the subject line
In D21916#488817, @romangg wrote:There are now two open reviews and a merged patch to 5.16
that wasn't merged back to master(now merged back by Vlad) and apparently induces a regression on openQA. The merged patch didn't reference its review. All open reviews don't reference each other.What I mean by that: It's difficult for me and probably other people as well to have an overview of which patch does what and how they are all connected with each other. Please create an overview task where you describe the overall goal of these patches and the intend of each patch singularly. Reference all patches in the task and in between each other when it makes sense.
Jul 1 2019
Make sure that the default framebuffer is bound when checking the color encoding.
Jun 29 2019
Jun 23 2019
Jun 20 2019
In D21916#482561, @zzag wrote:This happens on all platforms with Intel.
In D21916#482461, @zzag wrote:Now eglCreatePlatformWindowSurface fails with EGL_BAD_MATCH.
So this is kind of embarrassing, but it turns out that EGL_NONE is not defined to 0.
In D21908#482184, @ngraham wrote:In D21908#482152, @fredrik wrote:Yeah, I somehow had the idea that we always use GLES on Wayland, which would have made it unaffected by the bug.
It will need a similar patch.Does D21916 take care of it, or is that patch for something else?
Jun 19 2019
In D21908#482053, @sbergeron wrote:Is the code here common between X11 and Wayland sessions? Or is there other code involved for Wayland that needs to be addressed separately? 408594 is reproduceable for me on Wayland as well as X11, which is why I ask.
EDIT: a user on the bug report confirmed this works on X11 but the bug is still present on Wayland session, feel free to disregard the original question
Jun 16 2019
In D18377#480824, @zzag wrote:In D18377#480776, @anemeth wrote:I just downloaded the KDE Neon 5.16 iso from the website, installed it and updated it
You need an Intel graphics card to reproduce this bug.
May 27 2019
A display typeface is a typeface optimized for large headings and billboards.
So the term "display" has nothing to do with computer displays.
May 8 2019
In D19867#462617, @davidedmundson wrote:That'd be a nice easy fix at least.
Here's a patch: https://phabricator.kde.org/P385
I think it might tear because we have the threaded render loop so it's got no reason to be in sync with kwin/anything - but it looks to me to work fine.
Do we actually want the QtQuick rendering to sync to vblank in this case?
If not, the solution could be to set the swap interval for those drawables to zero.
Jan 31 2019
Looks good to me.
Jan 27 2019
In D18377#400445, @zzag wrote:May it cause issues on GLES?
Jan 26 2019
In D18377#400171, @anemeth wrote:
Jan 23 2019
In D18377#398821, @zzag wrote:Hmm, it looks like during each render pass we'll be wasting resources on "sRGB - linear RGB" conversions. Intermediate results should be in linear colorspace.
Nov 26 2018
In D13575#366344, @zzag wrote:So, if I understand you correctly, we could have either WindowQuadShadow/WindowQuadContents/WindowQuadDecoration/WindowQuadSubSurface or WindowQuadComposite(which is the union of the previously mentioned quads), depending on what an effect would like to do, right?
In D13575#366246, @zzag wrote:Another way to fix this problem is to render an untransformed window into an off-screen texture, then map it on the screen. The problem with this method is that we probably would need to get rid of different window quad types (e.g. WindowQuadShadow, WindowQuadDecoration, etc), which might break some effects, like the Screenshot. This would probably also fix T4441. We could maybe introduce different flags to control what parts of windows(e.g. shadows, etc) are rendered.
Difficult.
Jun 19 2018
It would be easy to change WindowForceBlurRole from a bool to an int, and have effects increment/decrement the value though.
Jun 17 2018
In D13382#279309, @zzag wrote:In D13382#279308, @fredrik wrote:My preferred long term solution to this problem would be to render the window untransformed to a texture, and transform that texture instead of the individual parts. This is something kwin will have to do anyway to implement wayland sub-surfaces in a conformant manner.
Yeah, it sounds better and would work for both X11 and Wayland. So, we don't need D13575, right?
My preferred long term solution to this problem would be to render the window untransformed to a texture, and transform that texture instead of the individual parts. This is something kwin will have to do anyway to implement wayland sub-surfaces in a conformant manner.
Jun 7 2018
Array textures wouldn't help in this case, because all layers must have the same size.
Apr 22 2018
Looks good to me, but I'd also check with @davidedmundson.
Apr 21 2018
@ervin I think you are confusing me with someone else here.
Apr 11 2018
In D10747#237235, @romangg wrote:Regarding the "drm_fourcc.h" file: do we want to copy it in KWayland's code base or could we use the system one? It's only available on Linux? In this case could we include it as a dummy only on non-Linunx systems? This way we could use the system one on Linux.
Mar 27 2018
Mar 19 2018
Fix issues pointed out by romangg.
In D10750#224860, @romangg wrote:In D10750#216337, @fredrik wrote:An issue that this patch does not fully address is switching compositing backends at runtime.
Do we support that at all? The backend is set at startup. Don't think you can change this later on.
Mar 18 2018
Rebase on master.
Mar 17 2018
In D10251#227092, @broulik wrote:What's the state of this? Bug 391915 just cropped up
Mar 14 2018
Mar 13 2018
Mar 12 2018
Import the context.
Mar 7 2018
Import the context.
Mar 1 2018
An issue that this patch does not fully address is switching compositing backends at runtime.
Feb 23 2018
In D10750#211784, @graesslin wrote:Concerning the tests: the ones requiring OpenGL work best if module vgem is loaded. That normally makes them pass. The tests regarding keyboard layout need env variable XDG_DEFAULT_LAYOUT being unset or on us.