This one brings a few rather important fixes:

- Major: ‘Forced render’ now happens in a separate context, which causes a lot less crashes when opening and paint
- Zoom on larges images works (no more transparent areas in full CoreImage mode) - ROI was wrong
- Progress window now shows up correctly (previously it didn’t show up very often because it wasn’t correctly threaded)

Update and have fun. I wonder if this fixess the infamous 32 bit painting problems on MacBook Pro?

And we are with a new release. As always, some big bugs left but time is short, so I’ll release the progress so far:

- Rewrote (yes once again) OpenGL display mode with PBuffers and variable texture sizes. Short said: Faster, smoother.
- Fixed ‘crop on visible pixels’
- Fixed selection problems with odd sizes
- ChocoImage bundles can now be opened if they have accents or spaces
- Optimized ScanMaskBounds (update selection contour)
- Saving small transparent images (32×32) seems to work now
- Accept first click when painting on window
- glDeleteTextures is called when necessary
- Condensed icons in main toolbar to reduce size on screen.
- recreate textures if image size is reduced
- added / cleaned up some resolution presets
- and so many little things….

There are a lot of other entries in the log but they mostly refer to the first point in this list which involved a lot of other changes / fixes. This release will make quite a difference if you have low-end hardware. Otherwise you’ll only benefit from some miscellaneous fixes. Note that it might be (much) faster now if you decided to use OpenGL mode on an accelerated machine (which you shouldn’t need to do anyway).

I think (hope?) this time I am done with the OpenGL mode. It is now fairly usable on a MacMini G4 or iBook. I can finally switch to my MacBook Pro after that. I mean if I ever receive it that is…

So, go on, update and report.

Since some people out there asked about it, I have now setup a mini-shop where you can make a donation to help development of ChocoFlop… for a very reasonable 14.99 Euros (or more if you happen to be rich) you can prepurchase a license of ChocoFlop.

You should really consider it as a donation first, rather than a purchase but by donating you’ll actually get into a database of users who will automatically get a license in the end for the final version.

Hm, I have been told that painting is still blocky in 32 bits mode on a MacBook Pro. The recently introduced 64 bits mode and the good old 128 bits mode are fine.

I really wonder what this is about…

I seems the ‘garbage around image’ on first run is still true. You can of course zoom in to fix this. Sadly I can’t reproduce this either on my iBook or my PC.

Quite a big update today. There are still some things to fix but Sunday is over so I’ll get back to this later. Here is a list of the main changes, followed by a post explaining in detail.

- You can chose if you wish to zoom using CoreImage or OpenGL (you see squares in the background when using CoreImage)
- Created nice looking pointers for all selection tools: lasso, oval, rectangle, magic wand (and no magic wand is still not implemented)
- Selection now look much nicer and cleaner. Only 1 pixel wide (with 1 black pixel around).
- You can see both the current selection and the previous one when adding/subtracting, without glitches.
- I wrote my own cikernel for zooming and pixellating. It might be faster on some hardware than an NSAffineTransform+Pixellate
- Added support for 64 bits per pixels mode (in addition to 32 and 128)
- A lot of other fixes for either speed or stability (see changelog if you care).

Now about this OpenGL vs CoreImage thing :

CoreImage is both a joy and a big source of frustration. If you have a MacBook Pro (which will be my case soon, yay!) it’s all pretty fast. But if you have poor iBook with CPU-only CoreImage operations just like mine (for one last week) things are quite different. You can easily understand that on this hardware you have to wait for filters to update… but it’s not only slow when filtering.

Just zooming and pixellating is slow on my iBook! Using a NSAffineTransform + Pixellate just takes all the CPU making all the other operations (lasso selection for example) lag like hell. Sadly you have to zoom and pixellate all the time in such kind of application. The solution I had found in the very early versions of ChocoFlop was to render on OpenGL Textures. These could easily be panned /zoomed around with pixellation and it is a very fast technique for final display.

Later I realized that doing this implied copying the image to the main memory. In the case of a GPU accelerated machine this simply *kills* the performance since all the data being processed in the GPU has to go back to the CPU (and back again). For some time I went all CoreImage. But now that I am going to part with my beloved iBook for a much more powerful machine I decided to do what I could to make the experience on lower machines at least pleasant, if not amazing like on more powerful hardware. So from now on you can chose between zooming with CoreImage and zooming with OpenGL. If your machine does not support pixel shaders it will default to OpenGL textures otherwise CoreImage will be used. You can easily tell which mode you’re using. If you’re in 100% CoreImage mode you’ll see squares in the background (outside of the image). You can force one mode or another from the ‘technical’ tab in the prefs.

It is still not perfect though… converting to OpenGL textures takes some time, and you’ll soon see a message while updating textures. So if you can upgrade your graphics cards, do it! But at least with this OpenGL mode you can draw with your lasso when zoomed and there’s no lag.

So update, and have fun!

I have had reports that on a MacBook Pro painting now outputs a bunch of crap…. can anyonce confirms this? Of course this does not happen on my machine(s).

There were number of reasons why painting was slow in certain cases. This new version will make zooming and panning look less smooth than before on certain machines (such as my Ibook). But it will make painting on a zoomed area quite fast, even on my lowly iBook. I still need to check that this still works correctly on an accelerated machine but I doubt I won’t be better too. You’ll probably notice a big difference especially if you zoom on a small area of a big image and start painting.

This also fixes some annoying bugs such as the infamous ‘initializing document’ and any problem due to sync problems for the progress window. Also quite some rewriting has been done to handle better threading operations.

Finally now this version defaults to 128 bits for both creation or opening documents. If you have old settings it will keep them of course. 32 bits is a bit faster on my iBook but I thought that this was a good idea for a default, since many people will have accelerated GPUs and also potentially probleems when painting in 32 bits (see previous posts on this).

Update to the new version!

No, not the game. the painting speed.

As I might have explained, to avoid lockups with 10.4.6 the solution I used was to force rendering the stack at certain key steps. This didn’t affect much speed on my iBook but totally killed the amazing speed on accelerated machines. Then I realized I could force that rendering, but using the same opengl context, just with a scissor test and a 0 pixel size. The effect is the same, no more lockups, the difference is that now the data doesn’t have to go back and forth from the GPU to the main memory so it’s prety pretty fast again.

Another problem that has been here for a while is that I couldn’t clear only the modified zones in the paintbuffers I used. It seems CoreImage’s Lazy rendering totally refuses to fill an accumulator with transparency. It just does nothing. So far I recreated the accumulators on each stroke which wasn’t optimal. Finally I settled up on using another accumulator just to do the clearing. Once again, we’re using some more memory to increase speed but it might be worth it.

So enjoy the speed. It flies now on a certain PC while still being decent on my iBook. Just update the app or get it from the download page.

A friend of mine who is the lucky owner of a MacBook Pro has sent me this screenshot. Apparently when he draws a lot of areas do not get refreshed. Somehow this does not happen on my iBook but has been confirmed to happen on a dual g5 with a radeon 9800.

After some testing it seems this is not a refresh problem but that the file just like that when saved! Does this happen on your machine?

Click for a bigger image.

I’d love to hear from you dear users, testers, brothers and sisters.

Hint: In the meantime you can use 128 bits mode. This painting problem only seems to happen on certain machines but only in 32 bits mode. 128 bit modes look fine. That’s weired since it’s the exact same code. The only difference is the CIImageAccumulator is 128 in one case and 32 bits in the other. This might be an Apple implementation issue. If someone has a machine with 10.4.5 and early on a dual cpu machine I’d love to hear about their experiences, maybe this was also caused by the differences in the new 10.4.6 update.

I’ll take a break now but first I am getting out a small release to fix two stupid useability bugs recently added.

- 1 pixel brush (non smoothed) is now 1 pixel, not 3… and square pixel brushes are the right size.
- you can now again use the alt key to subtract from a selection (this brought up the color picker, even with selection tools)