I did not manage to blog, I spend too much time with computer, all my related work is with computer, so I’m happy when I’m away for a while. And blogging about Google Summer of Code 2008 was not so important, but i want to change that.
So first, i had to learn billion of new information. I spend quite some time learning Qt 4.4. I used to like Java Swing and their name conventions for stuff, so now I’m learning names like QPixmap (maybe BufferedImage), slot-signal (action-listener), widget (JFrame? JPanel?) etc. Also i spend some time learning KOffice/Krita API.
I also spend a lot of time learning and studying various line algorithms.
I implemented Wu lines without thickness support, DDA line algorithm and Gupta-Sproul line algorithm with thickness support. The last one was taken from this work, sources are in lines.tar.gz.
They also contains some more lines algorithms like Nelson, Bresensham etc. Me and boud have contacted author about using his code. If it fails, I will re-implement it by myself. There is quite good description in Gupta and Sproul paper.
Wu lines are implemented according this:
My question answered:
What is pipe brush?
Brush can be represented by image. Pipe brush is brush that is represented by more images. In Gimp you create image with
more layers and then you save it like .gih. So you got pipe brush.
Pipe brush is a brush, that sprays a sequence of images.
What is dab and why we have splitCoordinate?
Dab is a point in a line. If you put all the points at integer positions, you get a staircase effect. Hence you need to anti-alias.So to anti-alias, you need to figure out the position of a dab at fractions of integer coordinates.
Hotspot is the area of the brush exactly under the cursor.
I found this code in kis_airbrush.cc:
QPointF hotSpot = brush->hotSpot(scale, scale);
How to draw within paintOp plug-in?
There are two steps:
First you create a new temporary KisPaintDevice, then create a KisRandomAccessor (KisPaintDevice:: createRandomAccessor) on that temporary paint device.
Than use that to write the pixel values you calculate in your […put your routine here…]
— line drawing routines. (that’s more efficient than using KisPaintDevice::setPixel).
Finally bitBlt the temporary paint onto the target, using the KisPainter.
Extent is not extend? No, it is not!
Krita layers don’t have a fixed size: they grow if you write to pixels outside the current extent. It takes more time to figure out
what the exact bounds are than it takes to composite the extra pixels
Why layers do not have exact size?
So they can grow — that’s a very nice behaviour. When you create a new paint device it’s empty, so it doesn’t take memory.
Check carefully the constructor KisPaintDevice — it doesn’t say anything about a size
Krita layers don’t have a fixed size, so Krita Layers are KisPaintDevices?
No, layers _have_ KisPaintDevices.
Why is KisPaintDevice::SetPixel is slow?
That’s quite slow, because for every call to setPixel a new iterator/accessor is being created.
If it weren’t so useful for scripts, setPixel would probably already have been removed from the API
Thank you, boud, for getting answers!