Hardware limitation - GL_MAX_TEXTURE_SIZE of 4096x4096 is still more or less common.
(you seem to be lucky on 8192x8192)
The only way to work around that /i know of/ is to tile textures, i.e. break the window in several quads below the texture size, tile the texture and attach the tiles to the quads, what is -ihmo- for this very purpose complete overhead.

If you /need/ windows of this size you'll have to disable compositing or use the XRender backend - but prepare for bad performance in either case.

I just mark this as WON'T FIX because it's _not_ exactly an UPSTREAM bug (you could purchase a far more expensive GPU ;-) and the amount of displays that can show windows of that size is still very limited.

This is something we need to fix as it's possible to reach the maximum texture size very easily on a multi-monitor system and we can't exactly just call it a hardware "bug" that we can ignore...

(In reply to comment #2)
> ... as it's possible to reach the maximum texture size very easily on a multi-monitor system
Unlikely, because

a)  GL_MAX_VIEWPORT_DIMS tends to equal GL_MAX_TEXTURE_SIZE (glxinfo -l) so 
you could not create a viewport of this size

b) non of my GPU's promotes available display setup combinations that exeed these limits (the 4k^2 one provides 2x2048x1536) - compositing or not ;-)

c) you can have (a horizontal row of) 2x1920x1200 on 4k^2 cards (nividia ~GF FX - GF7xxx) or 4x1920x1200 or 3x2560x1600 on 8k^2 cards (nvidia > GF7xxx, i assume ati matches in generation, don't know about intel) and afaik only pro cards (matrox m, quadro, firegl) support > 2 displays per card anyway

So 
- I agree that KWin should handle this condition, but
- I'd still consider it being exceptional, unexpected and even rather unwanted (e.g. result of  a resize bug) and
- recommand to
a) allow to prevent or ask on such resize requests (as the [uncomposited update] performance is horrible when the limit is exceeded)
b) suspend compositing and/or inform the user

Marking as NEW as -whatever the solution may be- the bug exists for sure and is explainable.

(In reply to comment #3)
> a)  GL_MAX_VIEWPORT_DIMS tends to equal GL_MAX_TEXTURE_SIZE (glxinfo -l) so 
> you could not create a viewport of this size

If this is always true then I guess the best solution would be to automatically disable compositing with an explanation why. As to where to detect this I cannot decide since it's possible to have a window < MAX but a decoration that's > MAX. Should it be in both the window redirect code and decoration code, the generic texture code (And die if any effect attempts to create a huge texture) or just the window redirect code (And ignore the decoration)?

I vote for generic texture code. If an effect attempts to create a huge texture it is clearly a bug and we might get a bug report if the user get's a nice notification.

(In reply to comment #4)
> If this is always true then I guess the best solution would be to automatically
> disable compositing with an explanation why.

..."tends"

For newer (consumer) cards (4k & 8k): yes (meaning "i've not seen any other")

For older cards: no (i.e. can, but you could face 2k^2 or 4k^2 GL_MAX_VIEWPORT_DIMS with 512^2 - 2k^2 GL_MAX_TEXTURE_SIZE  - really old cards have 64^2 GL_MAX_TEXTURE_SIZE)
The only value one can really rely on (for all chips) is GL_MAX_TEXTURE_SIZE=64 :-(

One the other hand i /guess/ that few of these older cards (except matrox and pro variants) have multiple display connectors anyway (i know that no Geforce3 card had dual monitor support on windows ;-)

Another problem is, that one can not 100% rely on these values (though that's really an upstream bug) i.e. they could return invalid (<1) or just wrong values (checked google for *nix affection)

Long story short:
if we want to ensure support for (really) old and/or cheap GPUs (512 or 1024 breaks everywhere...) we'll have to go for texture tiling, just that this would probably require to break (copy) the window (and deco) pixmap into tiles and bind those - i've no idea if this is possible (aside the fallback solution) at all or the resulting performance is worth it - and might then interfere with the effects window segmentation *shrug*

For the location of a (bypassable) check i second martin as any huge texture would end up being black.

*** Bug 214596 has been marked as a duplicate of this bug. ***

*** Bug 223033 has been marked as a duplicate of this bug. ***

*** Bug 284941 has been marked as a duplicate of this bug. ***

*** Bug 280886 has been marked as a duplicate of this bug. ***

*** Bug 287842 has been marked as a duplicate of this bug. ***

*** Bug 298979 has been marked as a duplicate of this bug. ***

*** Bug 298979 has been marked as a duplicate of this bug. ***

*** Bug 301142 has been marked as a duplicate of this bug. ***

*** Bug 305920 has been marked as a duplicate of this bug. ***

It does not disappear in my case, but it turns completely black!

Operating System: Manjaro Linux 
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.14.1
Kernel Version: 5.5.6-1-MANJARO

Graphics:  Device-1: Intel HD Graphics 620 driver: i915 v: kernel 
           Display: x11 server: X.Org 1.20.7 driver: intel unloaded: modesetting resolution: 2560x1440~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 620 (Kaby Lake GT2) v: 4.6 Mesa 19.3.4 

Compositor: OpenGL3.1

Created attachment 126506 [details]
Screen recording. 1) Without compositing 2) OpenGL3.1

I did screen recording of the issue. First part shows the issue deactivated compositor (ctrl+shift+F12). The second part with activated compositor (OpenGL3.1). The flickering can only be seen on the video.

Since the original report almost all graphic cards max texture sizes have grown and grown. We are also seeing more and more clients switch to providing GL textures over raster at which point this issue is moot as it will be client side.

For that reason it is not worth the added complexity within kwin to support this.