Krita/Redisplay

Some notes taken from irc about the way krita's redisplay routine works. (Should be worked out more cleanly)

[11:19] <Thrain_true> boud: if I understand correctly, KisLayerShape is what we used to call "the Krita shape"
[11:19] <Thrain_true> when it's active, "krita tools" are loaded
[11:20] <Thrain_true> external shapes are drawn on the KisShapeLayer
[11:20] <Thrain_true> boud: right?
[11:20] <boud> Thrain_true: yes, in a measure
[11:20] <Thrain_true> mh
[11:20] <Thrain_true> boud: another thing
[11:20] <boud> Thrain_true: KisLayerShape is only for use in Krita; for external shape users, we'll have a KisImageShape once I get time to create it.
[11:21] <Thrain_true> boud: where KisCanvas and KisView are?
[11:21] <Thrain_true> I mean
[11:21] <Thrain_true> a KisLayerShape has a KisPaintDevice, and a KisDoc has a KisImage
[11:21] <Thrain_true> KisView shows the Layer stack
[11:21] <Thrain_true> KisCanvas? Draws the stack?
[11:22] <boud> KisCanvas2 is the wrapper around KisQPainterCanvas and KisOpenGLCanvas who draw the image on screen
[11:22] <Thrain_true> ok
[11:22] <Thrain_true> KisView, then?
[11:23] <Thrain_true> KisView shows the Canvas & the toolbars?
[11:23] <boud> The chain is: KisPainter paints on a layer, layer is set dirty, that percolates up to the KisGroupLayer that is the rootlayer. The rootlayer informs the KisProjection that there's need for an update of the projection
[11:23] <boud> wait...
[11:24] <Thrain_true> ok
[11:24] <boud> KisProjection updates the dirty bits of the projection (in threads since yesterday), kisprojection informs KisImage that a chunk has been updated, which informs kisview, which informs KisCanvas2; KisCanvas2 converts the projection to a QImage
[11:24] <boud> And then ask Qt to schedule a paintEvent for KisQPainterCanvas (or KisOpenGLCanvas, once that has bene ported); and KisQPainterCanvas scales the image and puts it on screen
[11:25] <boud> KisView ties the canvas, the toolbox, the dockers and the various managers for htings like selections, layers etc. together
[11:25] <Thrain_true> okok
[11:25] <boud> KisImage knows which layer is its root layer (which is always a group layer) and which layer is active (which may be of any type)
[11:26] <Thrain_true> that's when we draw with KisPainter
[11:26] <Thrain_true> and when we draw the "preview" (what we used to do with KisCanvasPainter, and now with QPainter)
[11:26] <Thrain_true> what happens?
[11:26] <boud> KisPainter is used to draw on layers with paintops, other paint devices, fill layers or convolve layers.
[11:27] <Thrain_true> yes yes I understood that
[11:27] <Thrain_true> but before using KisPainter to "stroke" the drawing, we use QPainter to show the "preview", am I explaining what I mean'
[11:27] <Thrain_true> ?
[11:27] <boud> Those are the tool decorations: the temporary lines for a rect tool, or the bezier lines with control points for your tools; for that, during the paintEvent of the KisQPainterCanvas (or later, KisOpenGLCanvas)..
[11:28] <Thrain_true> mhhhh
[11:28] <boud> a call is placed to KoTool::paint(painter, viewconverter)
[11:28] * Thrain_true doesn't get why we need KisOpenGLCanvas since Qt can draw directly on OpenGL with QPainter
[11:28] <boud> (the re-implementations of that method, rather)
[11:28] <Thrain_true> mhhhh
[11:28] * Thrain_true thinks
[11:29] <Thrain_true> so the tools draw directly on KisCanvas
[11:29] <boud> The biggest change since 1.6 is that tools need to draw inside the paintevent of the canvas widget
[11:29] <boud> The tools get a reference to a QPainter and use that to draw; they shouldn't know or care whether that QPainter paints on a widget, a QImage, a QPixmap or any other QPaintDevice implementation.
[11:30] <boud> KisCanvas2 is not a widget, actually, it's just a wrapper around the actual canvas widgets
[11:30] <Thrain_true> yes yes I understand what's KisCanvas2
[11:30] <boud> we need the opengl canvas because Qt won't use opengl when drawing on an ordinary widget; you need an opengl widget for that.
[11:30] <Thrain_true> but KoTool::paint will draw with QPainter onto KisQPainterCanvas throught KisCanvas2
[11:31] <boud> No, not quite.
[11:31] <Thrain_true> ah
[11:31] <Thrain_true> Mh :p
[11:31] <boud> KoTool::paint will draw on a QPainter.
[11:31] <Thrain_true> a QPainter?
[11:31] <boud> Yes. The call to KoTool::paint() is done in the canvas widget.
[11:31] <Thrain_true> "on a QPainter" or "with a QPainter"
[11:31] <Thrain_true> ahhh ok I get it
[11:32] <boud> look at kis_qpainter_canvas line 221
[11:32] <Thrain_true> mhmhmhm
[11:33] * Thrain_true needs a log of this conversation
[11:33] <Thrain_true> boud can you take it? I'm on windows at the moment
[11:34] * Thrain_true thinks
[11:34] <boud> sure, I'll paste it on the wiki.
[11:34] <boud> We need a bit of documentation on how krita works anyway.
[11:35] <Thrain_true> boud: another thing... you said that something doesn't draw
[11:35] <Thrain_true> is KisShapeLayer?
[11:35] <Thrain_true> I mean
[11:35] <Thrain_true> you couldn't get external shapes drawn?
[11:35] <boud> Thrain_true: yes
[11:35] <Thrain_true> ok
[11:35] <Thrain_true> mh
[11:35] <boud> I tried two things:
[11:35] <boud> paint on a qimage KisShapeLayer::prepareProjection
[11:36] <Thrain_true> neither the decorations?
[11:36] <boud> Since no actual shapes are selected, the only decorations are from the default tool -- the one you can move & rotate and sheer with.
[11:36] <boud> I also messed up with conversions from flake-internal points to image pixels.
[11:37] <Thrain_true> yep but you have to create the shape first
[11:37] <boud> That's no problem, that's done for you
[11:37] <boud> If you drag a shape from the shape selector onto the canvas, Krita (through flake) creates a shape all right
[11:37] <Thrain_true> what does it mean "that's done for you"? Haven't I to select the creation tool?
[11:37] <Thrain_true> ah ok ok
[11:37] <boud> And in kis_doc2.cc is the code that creates shape layers
[11:37] <Thrain_true> I meant that
[11:37] <boud> Nope, you can just drag & drop from the toolbox with example shapes
[11:39] <Thrain_true> bof
[11:39] --> BCoppens has joined this channel (n=bartcopp@kde/developer/coppens).
[11:39] <boud> At least, I could yesterday, right now krita crashes again. But this time when it tries to paint the shape.
[11:39] <boud> That's progress, even if I don't know why -- I didn't change anything.
[11:40] <Thrain_true> ok, probably I've to wait before coding something because I've to svn up against svn (I'm currectly svn'ing against anonsvn)
[11:40] <boud> ok
[11:41] <Thrain_true> boud: KisToolRegistry still exists?
[11:41] <boud> No, it's now KoToolRegistry
[11:41] * Thrain_true hates English questions costruction
[11:41] <Thrain_true> :)
[11:41] <Thrain_true> boud: good
[11:41] <Thrain_true> mhhh
[11:42] <Thrain_true> boud: another question :)
[11:42] <boud> Basically, the tool porting thing is solved, it's just a lot of work to finish it.
[11:42] <Thrain_true> there is the "shape selector"
[11:42] <boud> (And for zoom/pan tools we will need to do something different and more generic)
[11:43] <Thrain_true> but this has to be implemented by each KOffice application since each initialize the shape in a different way
[11:43] <Thrain_true> I mean
[11:43] <Thrain_true> Krita need to create a KisShapeLayer
[11:43] <Thrain_true> Kword needs to create another thing I guess
[11:44] <boud> For Krita, that;s done in kis_doc2.cc
[11:44] <Thrain_true> mhh
[11:44] <boud> Basically, there are two methods, addShape and removeShape that I have implemented to create shape layers whenever a shape is added.
[11:45] <boud> It's the implementation of KoShapeControllerBase
[11:45] <Thrain_true> ok but how does it fit with the shape selector?
[11:45] <Thrain_true> ahhhh ok
[11:45] <boud> Fully automatically :-)
[11:45] <Thrain_true> I meant that :)
[11:45] <Thrain_true> so KisDoc is the implementation of KoShapeControllerBase
[11:45] <Thrain_true> (KisDoc2)