Aye, I've ran the msi in cyohash, and the SHA1 is the same.

First impressions are that OpenGL is working just fine. I'm using Windows 7 SP1 64-bit with a Nvidia GeForce 310M. Canvas rotation and scaling along with shift-drag brush resizing are much smoother and more intuitive. It's all very impressive. Great work!

Update:
I found the culprit! I disabled the virus scanner and this time the kparts.dll file was installed correctly. Krita launched without a hitch.
So it wasn't a windows thing after all.

Edit:
first impressions: very good, nice to see the brush tagging system is improved.
I wasn't aware how it works at first, but it's explained well here:https://git.reviewboard.kde.org/r/110429/
Bravo!

disabling antivurus did the trick for me too. Krita works very fast. But lack of palette tool-bar is very bad.
It seems I have to disable antivirus every time i run Krita or there is an error and it wont start.
Enabling OpengGl is slower for me, but it works.
Installation is much faster now and it is awesome.

Stirrup wrote:nice to see the brush tagging system is improved.

I just updated another review request that improves the system even further and which will find its way into master soon, probably

https://git.reviewboard.kde.org/r/110541/
Fixes all sorts of issues.
Tags are now sorted alphabetically, are synchronized across all dockers that share the same type of resources, a nicer context menu, and tags now update without having to restart Krita.

Context menu will get another update later after this one.
I plan on making it possible to populate tags with resources with purely using the mouse, as well. Should make things even more comfortable.

@JoseConseco:
You don't need to disable the antivirus everytime, you can add an exclusion rule so it won't be scanned for viruses (and leaving the essential files alone). In my case, adding the folder location of Krita worked out fine.

@sascha_s:
Oooh very nice! Keep up the good work!

Really weird... I don't understand why kparts.dll should trigger a virus scanner...

Which virus scanner is that, btw?

I have Norton Internet security at work.

Same.
I've checked the history of the scanner and it seems more dll files were deleted during the installation, lib/kde4.
They were marked as "Suspicious.Cloud.7.F" . My guess is that Norton tends to be overprotective and mark every new unknown file as unsafe.

Just for a record - Avast! is not making any problems when it comes to install or run Krita.

Tried yesterday the 2.7.8.2.
The installation went pretty fast, the Comodo Internet Security 5 didn't corrupt the install. Krita ran pretty stable, both with enabled and disabled OpenGL. But what bothers me is the brush engine. Simple brushes (or of small size) run very fast and smooth, but when I try to use a big airbrush, or one of the textured+smearing brushes by deevad (http://www.davidrevoy.com/article123/krita-brushkit-v2) - they lag drastically, loading the CPU up to 90% - the stroke may appear 2-3 seconds after I draw on the tablet... It happens irrelevant to the OpenGL option. It this an expected behavior, or something isn't right?

Windows 7 x64, Core2Duo E8400, Nvidia GeForce GTX 660Ti, Wacom Bamboo Fun Pen&Touch Small CTH-470S. All the drivers are fresh.

boudewijn, thank you for the hard work!

Hm, no it should be fine really. Your cpu doesn't yet have AVX which does make a difference, though it supports SSE up to 4.1, which Krita does use.

Hello, I am encountering an issue with the relatively recent Windows Krita builds (including the new much faster 2.7.8.2). I'm a fresh KDE forum poster, please bear with me as I try to describe it in detail.


The problem arises with the use of my tablet. Quite often, strokes simply fail to draw on the canvas. When it does draw, it works as expected, but when it doesn't even as the stylus is applied, nothing draws and it behaves as if the click event didn't register.

This happens regardless of the tool used, I've tested with the selection ones and of course the brush tool.

This only happens on the canvas. The tablet can be used just as well on the menus or anywhere else on the interface, even in between two attempted strokes on the canvas which fail to draw.

This only happens when using the tablet, and not when only using the mouse. However, once this has manifested, the mouse also does not register on the canvas for the very first stroke applied immediately after using the tablet. Thereafter, the mouse works predictably, yet the tablet still manifests this behavior.

I tested by trying to make many parallel strokes with the brush, and it seems when it starts skipping, it stays that way for a few seconds before becoming normal again; that is to say that the skipped and drawn strokes are usually grouped together.


Now, my first suspicion would be that this is a tablet issue. But the tablet works completely fine everywhere else on Windows: I regularly use GIMP (2.8.4), as well as Mypaint (1.0.0, the last working Windows build afaik). The tablet also works fine on Linux, even on Krita (2.6). There were no driver changes for the tablet within the phase I started encountering this behavior, and no system change that I know of.

And what more, this behavior is relatively recent. I've experimented with boudewijn builds since around 2.5~2.6 and I didn't encounter it before (even though there were other problems which have since delightfully disappeared :) I don't clearly remember which version I first noticed this in, but the build just before the current smaller and faster one surely had it as well.


My system is Windows XP SP3 32bit.
My tablet is a Wacom Bamboo One, which uses the same drivers as the more common lines of Bamboo tablets, but is relatively rare.
My tablet driver is up to date as of January. (This behaviors was not noticed before or shortly after the driver update.)

I have only tried to duplicate this behavior on my friend's Windows machine running Windows 7 64bit. The behavior is successfully reproducible. However, he uses the same model of the tablet as I am, although his driver was found to be one releaseolder, so there may still be a hardware/driver problem, whether or not it is a newly visible regression in combination with Krita. I have access to no other Windows systems with tablets to test it on.


One additional report: The OpenGL canvas draw mode works quite speedily for me on my Nvidia GTS250 with up to date drivers. But it flickers and tears constantly with every draw update, making it usable but very disturbing. This is with or without the trilinear filter on.

The previously mentioned stroke skipping behavior occurs with or without OpenGL (and trilinear filter) on.

This tearing behavior does not occur with my friend's machine where OpenGL works flawlessly. Coincidentally, he has the same older Nvidia card as me, but a non up-to-date driver.


I hope this helps. :]

Does this windows version have unlimited canvas like mypaint?