If you have more than 1 curve based assistant, e.g. Fish Eye Point, Spline, Concentric Ellipse, zooming in will black screen part or all of the drawing window. It can be any combination of curved based assistants. For example, 2 Fish Eyes, 1 Spline & ! Fish Eye, 1 Concentric & 1 Spline will all cause the problem. The zoom factor at which this happens varies, but I believe it has to do with the position of the assistants' control points. Once a certain number of them are no longer visible in the UI the error is triggered. This does not happen with line based assistants, like Vanishing Point, Parallel Ruler, etc., but can happen with Perspective grid. Turning off Open GL eliminates the black screening of the drawing window, but without it the assistant preview lines don't function and the cursor leaves a 'permanent' light gray trail. This trail is strictly a display error and not part of the image, and can be removed by re-enabling OGL. Happens with both Windows 7 64bit SP 1 & Linux Mint 17 LTS, Nvidia 750 Ti This does NOT happen with Krita 2.9.11, so I assume it has something to do with the switch to QT. Reproducible: Always Steps to Reproduce: 1.Make at least 2 curve based assistants. Putting control points outside of the image will make it happen at lower zooms 2.Zoom in. Actual Results: Black screened drawing window Expected Results: Display the drawing window normally
Not a Krita issue. Updating to the latest Nvidia driver resolved this issue. (At least on Win 7, will try Mint later. These things take time on low end DSL)
Spoke to soon, Open GL was turned off in preferences. When re-enabled the issue still exists.
Yes, I'm pretty sure this is an opengl issue. I'm guessing that ats ome point, the OpenGL QPainter engine overflows something in thecard. Needless to say, it only happens on some cards/driver combinations; I cannot reproduce it on my Linux/Windows/NVidia development system...
I enabled performance & Open Gl logging to try and get you more info, but the only thing I get in the log folder are copies of any brush used(.kpp) & .stroke.rdata files for those brushes. Is that what's expected with logging? I also tested for the issue on a laptop with a nvidia GTX 280m and it happens there too. So either you're lucky or I'm very unlucky. I'm curious, what card & driver are you using? One interesting thing I've noticed with Fish eyes; editing the third point while holding the shift key should snap the eye to a perfect circle, but with multiple Fish eyes this modifier only works on the most recently create eye. Then if you delete all but one Fish eye the modifier will work on the remaining one, even if it wasn't the most recent. Open GL on/off does not effect this. With 2.9.11 this modifier always works as expected, with any number of eyes.
I've got a GeForce GTX 650 Ti, with the proprietary NVidia driver on Linux. I cannot check the version on Windows right now because I'm in the middle of a build... Could you see whether http://valdyas.org/~boud/krita-master-44fb938-x64.zip makes a difference? That's the same code, but built by a different compiler.
Unfortunately I still get the issues with the alternate build
Created attachment 98472 [details] assistant glitch test image
Since Boud can't reproduce this, I'm curious if anyone else is effected by the issue and have uploaded a small image that will let people easily test for it. On my machines, with any Krita v3, this image will load with the canvas blacked out and setting the zoom to a value of less than or equal to 58% will cause it to display correctly.
I am on a Windows 10 with NVIDIA GT650M. I cannot reproduce and get the black screen. I will say that I did have to update my graphics card drivers from what was installed by Windows. Doing the "Check for updates" through the windows drivers is not very reliable. I found out the model that I had and downloaded the drivers straight from NVIDIA. That seemed to fix any issues I once had.
(In reply to Scott Petrovic from comment #9) Yeah, I always go directly to Nvidia too. And that's the first thing I did after nobody else seemed to have this issue. But it didn't help ): After that I even tried doing 'important' updates via Windows Update, which I dread because sometimes it hurts more than it helps. Nothing bad happened, but it didn't fix things either. The next step is 'recommended' updates, if I have the courage. The strange thing is, it's not just a Win 7 issue. Both machines are dual boot, the desktop is Win7/ Mint 17/Nvidia 750 Ti and the laptop is Win7/Mint13/Nvidia 280m and I have the exact same issue on both machine with each OS. Which is just weird and me makes wonder if maybe it's VRAM. The 750 ti has 2048MB and the 280m has 1024MB. Does your card have more than that? Also the whole screen doesn't go black just the canvas or part of the canvas. It's hard to tell because of being zoomed in. Besides zooming out, panning some of the image off screen will make the black go away. The farther in you've zoomed in the more you have pan. Which doesn't qualify as a workaround, but is interesting
When you go to the properties of your driver update, what driver version are you on and what is the driver date? Mine driver date is 7/22/2015 and I am on version 10.18.13.5362 I don't know if Microsoft has that close of a relationship with NVIDIA to push out their graphic driver updates. My card has 2GB of VRAM, but I doubt that is the issue. If your one computer has a 280M, that means it is a few years older than mine. Sometimes with older graphics cards, NVIDIA stops supporting them and making updates. My other computer I updated to Windows 10, but my graphics card isn't supported on Windows 10, so I have hiccups and odd things that happen. Based off my old card, it looked like NVIDIA has a 5 year window on when they support graphics cards.
i was unable to reproduce the bug in krita 3.0 beta. windows 7 64 bit - nvidia gforce gt 610 im a bit late but i hope any extra information helps
My 750Ti driver is currently 364.72 (10.18.13.6472) March 28, 2016 and before I installed that, it was 355.98 (10.18.13.5598) September 22, 2015. On the 280M it's 341.95 (9.18.13.4195) dated March 16 2016. Previously it was 332.21 (9.18.13.3221) December 19, 2013. The 280M may be too old (Note the low numbering on the driver), but perhaps the 750Ti is too different, at least without a programmer being able to reproduce the issue and correct for it. I say too different because the 750Ti uses Nvidia's newer Maxwell architecture. Everyone who has responded so far has had a Series 600 card, which are Kepler architecture. I'd be very interested in anyone with one the following cards testing for this glitch. Maxwell 1st gen: 750Ti, 750, 960, 950 Maxwell 2nd gen: TITAN X, 980, 980Ti, 970, 960, 980M, 970M, 965M
Hi I tested on Win 7, Krita 3.0 Beta1 (99f6246) 64bit, Nvidia GeForce G 103M and I can't reproduce this bug... I using yours "assistant glitch test image" <- thank you for adding this, make easier to test.
I have the exact same card ( nvidia 750 ti 2gb) and I can reproduce the issue on windows 10. I tested with a driver dated 8/7/2015, I'll update the driver and text again , let me know if I can give any logs which may help find the issue more specifically
Still happens with new graphic drivers (11/5/2015) too
I can reproduce this in linux too with latest nvidia proprietary graphic drivers
My krita-opengl.txt only has the single line with the card & driver info. I've tried running krita in debug mode on the linux side, with dbgOpenGL set to true, but the issue doesn't to seem cause any hiccups in the log. As far as I know, I've never had this issue cause a crash.
I can actually reproduce this on Archlinux right now. zooming turns the screen black (at some point)
Created attachment 98948 [details] [ ^ short video of the bug ] Hi, reproduced on Ubuntu 16.04 Git~master, nvidia graphic too. GeForce GTX 650 Ti. I attach a short video.
Created attachment 99290 [details] Assistant glitch workaround demo image I've found a workaround for this, at least in regard to 5 point perspective using fisheye assistants. Attached is a blank image demonstrating this workaround. With it you can zoom in to your heart's content without the canvas blacking out (and it's surprising just how happy that makes me:)). The key to avoiding the issue is that the area defined by either fisheye must be completely outside of the image. Since fisheyes repeat themselves once on either side (along their defining line segment, a feature usually used for making panoramas) you will still get assisted drawing on the image if things are set up properly. Note: If you want to change the resolution of this demo image adjust pixels per inch or pixels per cenimeter. Assistants use points for their positional unit, and points key off of inches or centimeters, so if you scale the image any other way, the assistants will not match that scaling.
Update on the workaround: Well, sadly it's not perfect. You will still get partial canvas blackout if you zoom in on the top edge of the image, but even with that issue it still makes 5 point perspective completely doable in 3.0
I can also reproduce this bug on Linux + Qt 5.5.1
Git commit 34f8ecdf866b556c4a054003f6358a7cee6fa025 by Dmitry Kazakov. Committed on 16/08/2016 at 14:59. Pushed by dkazakov into branch 'master'. Workaround a NVIDIA/Qt but with black screen in assistants It seems like Qt uses some internal caches/textures for painting pixmaps/images on screen. And if the images of one rendering cycle don't fit into that cache they are painted and black rectangles. There is a workaround for that: just make the size of the pixmap cache more than 20 MiB. Then all the pixmaps painted through the cache will work correctly (if you decide to draw a QImage on screen manually, it still doesn't work). I don't know what happens there, but it seems like this workaround fixes the problem. Let's wait until we merge Qt+openGL3 branch, probably, it will change something. M +36 -0 libs/ui/opengl/kis_opengl.cpp M +5 -0 libs/ui/opengl/kis_opengl.h http://commits.kde.org/krita/34f8ecdf866b556c4a054003f6358a7cee6fa025
Git commit b520fe1920ed3e5d1caab994d814bf8bd1b07650 by Dmitry Kazakov, on behalf of Maciej Jesionowski. Committed on 15/11/2023 at 15:42. Pushed by dkazakov into branch 'master'. Draw assistants directly on the canvas Change the way assistants are rendered on the canvas. Instead of drawing the assistants into a pixmap, storing the pixmap in QPixmapCache, and then painting the pixmap onto the canvas, this patch skips the intermediate pixmap and draws the assistants directly on the canvas. The QPixmapCache method is prone to a bug where the pixmap is evicted from the cache before the rendering is complete, resulting in a black rectangle. Also this method performs very poorly with hardware acceleration, because we're doing a costly texture upload, texture sampling, and blending. The performance is especially bad when assistants take a large portion of the screen when zoomed in and the canvas is zoomed or rotated. Changes in this patch: - Add a menu option in Display settings to toggle assistants drawing mode - Use direct drawing mode by default - Remove the workaround detection for NVIDIA The old options are left for troubleshooting, but it's unlikely anyone would find them to work better on the current GPU hardware. Related: bug 401940 M +4 -0 libs/ui/KisDecorationsManager.cpp M +26 -10 libs/ui/dialogs/kis_dlg_preferences.cc M +49 -17 libs/ui/forms/wdgdisplaysettings.ui M +15 -0 libs/ui/kis_config.cc M +8 -0 libs/ui/kis_config.h M +1 -1 libs/ui/kis_painting_assistant.h M +15 -2 libs/ui/kis_painting_assistants_decoration.cpp M +1 -0 libs/ui/kis_painting_assistants_decoration.h M +9 -20 libs/ui/opengl/kis_opengl.cpp M +0 -5 libs/ui/opengl/kis_opengl.h https://invent.kde.org/graphics/krita/-/commit/b520fe1920ed3e5d1caab994d814bf8bd1b07650
Git commit da0fe44bb426e0acd96142a09682931208ab483d by Dmitry Kazakov, on behalf of Maciej Jesionowski. Committed on 15/11/2023 at 15:43. Pushed by dkazakov into branch 'krita/5.2'. Draw assistants directly on the canvas Change the way assistants are rendered on the canvas. Instead of drawing the assistants into a pixmap, storing the pixmap in QPixmapCache, and then painting the pixmap onto the canvas, this patch skips the intermediate pixmap and draws the assistants directly on the canvas. The QPixmapCache method is prone to a bug where the pixmap is evicted from the cache before the rendering is complete, resulting in a black rectangle. Also this method performs very poorly with hardware acceleration, because we're doing a costly texture upload, texture sampling, and blending. The performance is especially bad when assistants take a large portion of the screen when zoomed in and the canvas is zoomed or rotated. Changes in this patch: - Add a menu option in Display settings to toggle assistants drawing mode - Use direct drawing mode by default - Remove the workaround detection for NVIDIA The old options are left for troubleshooting, but it's unlikely anyone would find them to work better on the current GPU hardware. Related: bug 401940 M +4 -0 libs/ui/KisDecorationsManager.cpp M +26 -10 libs/ui/dialogs/kis_dlg_preferences.cc M +49 -17 libs/ui/forms/wdgdisplaysettings.ui M +15 -0 libs/ui/kis_config.cc M +8 -0 libs/ui/kis_config.h M +1 -1 libs/ui/kis_painting_assistant.h M +15 -2 libs/ui/kis_painting_assistants_decoration.cpp M +1 -0 libs/ui/kis_painting_assistants_decoration.h M +9 -20 libs/ui/opengl/kis_opengl.cpp M +0 -5 libs/ui/opengl/kis_opengl.h https://invent.kde.org/graphics/krita/-/commit/da0fe44bb426e0acd96142a09682931208ab483d