Opened 6 years ago
Last modified 3 years ago
#14340 closed bug
Black canvas overlay triggered within certain graphics applications — at Version 5
Reported by: | cocobean | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Servers/app_server | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description (last modified by )
The main canvas editing area of the graphics application shows a black overlay screen shortly after the canvas editing area appears. You can see the menus and panels or menus/panels may appear/disappear upon cursor movement over them. In Blender, the canvas area appears if trying to render an image and during the Blender splash screen when the app is launched - but disappears after you close the Blender splash screen image. In ArtPaint, the canvas area turns black but you can see the menu options and panels.
This issue is specific to Haiku x86_64 version for specific apps. Applications affected:
1. ArtPaint 2.1.2, 2.1.0git-7 2. Blender 2.79b
Seems to work: GrafX2, Becasso, TuxPaint, Krita, KolourPaint
Change History (8)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
No KDL issue beforehand. This happens on all recent x86_64 nightly snapshots since May 2018 - >hrev52201. Does not happen on same x86_gcc2 hrevs using Blender/ArtPaint/WonderBrush.
comment:3 by , 6 years ago
You should not compare x86_64 and x86_gcc2 Blender. The x86_gcc2 one - AFAIK - using native UI while the x86_64 uses SDL, but you can check it if you do objdump -x Blender | grep NEEDED
. If it is SDL based it must be listed there.
I think the missing hardware cursor support is the reason for the black blocky graphics glitches, but fixme.
comment:5 by , 5 years ago
Description: | modified (diff) |
---|
Is this preceded by a KDL?
And, what hrev did this begin occurring on?