Zooming in or out with the mouse wheel while moving any tool simultaneously causes krita's canvas to "lock up" until it's panned. Moving the any tool over the canvas after attempting to zoom while moving a tool leaves a "trail" in which the correct image can be seen. This could be a separate bug, but I suspect it's related, so I will put it here as well. Enabling OpenGL causes the canvas to lock completely, showing few changes. Zoom does not work, and the only tools that seem to show up when used are the move and ruler tools. Having the ruler tool equipped makes the problems completely disappear in both instances, for some reason. When the tool is replaced with another, the problem returns. Reproducible: Always Steps to Reproduce: 1. Move brush over canvas while zooming with mouse wheel. 2. 3. Actual Results: The bug is reproduced, canvas does not update. Expected Results: Software should have zoomed properly.
I've haven't tried to reproduce the first problem, but the second problem, the canvas not working in OpenGL mode sounds like a driver problem. Which driver version, GPU and Linux distribution are you using? Have you tried playing with the opengl settings, i.e, different scaling methods?
(In reply to Boudewijn Rempt from comment #1) > I've haven't tried to reproduce the first problem, but the second problem, > the canvas not working in OpenGL mode sounds like a driver problem. Which > driver version, GPU and Linux distribution are you using? Have you tried > playing with the opengl settings, i.e, different scaling methods? Sorry for taking so long to respond to this, but here is the information that you've requested. Currently, I'm running a new installation of Kubuntu 14.04. Although I've tried newer versions of the drivers and still experienced the problem, I'm currently running the "fglrx" drivers from the default repositories. The driver is version 13.35.5. I'm not sure what part of the terminal output on my graphics card is relevant, so I'll just post the entire thing: >01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] (prog-if 00 [VGA controller]) > Subsystem: ASUSTeK Computer Inc. Tahiti XTL [Radeon R9 280X DirectCU II TOP] > Flags: bus master, fast devsel, latency 0, IRQ 47 > Memory at e0000000 (64-bit, prefetchable) [size=256M] > Memory at f0000000 (64-bit, non-prefetchable) [size=256K] > I/O ports at e000 [size=256] > Expansion ROM at f0040000 [disabled] [size=128K] > Capabilities: [48] Vendor Specific Information: Len=08 <?> > Capabilities: [50] Power Management version 3 > Capabilities: [58] Express Legacy Endpoint, MSI 00 > Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> > Capabilities: [150] Advanced Error Reporting > Capabilities: [270] #19 > Capabilities: [2b0] Address Translation Service (ATS) > Capabilities: [2c0] #13 > Capabilities: [2d0] #1b > Kernel driver in use: fglrx_pci As for the opengl issue, I've attempted switching the scaling modes, and doing so makes no difference, and occasionally results in a crash. Strangely enough, the first issue even appears to still occurs under windows, so I'm not sure if it's related to the OS I'm running. I'm not sure how much the windows AMD drivers share with the linux ones, so I couldn't even begin to speculate on whether they're the cause of the problem. It may have something to do with the hardware, though. Also, I feel that I should disclose that I'm using a dual monitor setup as well, although whether or not the second monitor is active seems to be irrelevant to whether or not the issue occurs. I hope the information provided is relevant and useful.
I cannot reproduce the problem either :(
(In reply to Dmitry Kazakov from comment #3) > I cannot reproduce the problem either :( That's really unfortunate. Is there anything I could do, or any other information I could provide to help?
UPDATE: I was able to avert the OpenGL bug by running ubuntu's default radeon drivers, so I suspect that's a driver issue of some sort. The issue with mouse wheel zooming still occurs while opengl is disabled, however. I'll report back if it's the same case under windows. I suspect that the issues are in fact separate, and the one that occurs while opengl is disabled may be related to this one in some way: https://bugs.kde.org/show_bug.cgi?id=337733
Hm, ok... In that case, I'll close this as a duplicate of that bug, because it does seem to be the same issue. *** This bug has been marked as a duplicate of bug 337733 ***