[Kde-graphics-devel] Status update

[Mosfet-2]

I decided to just try to finish up the first alpha of libmimage instead of
doing a bunch of backporting. That way people can test the code I actually
use then I can backport to KDE once. Seems to make more sense.

For people who are wondering, this is what I want to work on in order of
release:

1) libmimage
2) The MIMS photo browser, (the successor to PixiePlus). Chris Howells is
currently maintaining the old version of PixiePlus in kdenonbeta and knows
about the new one.
3) libmultilayer (64bit tiled, layered image library)
4) MIMS Paint
 
I got a new hard drive for Christmas and am currently downloading software for
rebuilding my system. I'll be offline for a day or two, but if anyone wants
to send me email I'll still get it. I just may not reply right away.

[Mosfet-2]

Just so you all know, I'm back.

I finally got a new hard drive so rebuilt my system from scratch (LFS system
w/ gcc 3.4.3, libc 2.3.4, Xorg CVS, KDE CVS). It's been a while since I've
been able to check out KDE CVS head.

I also got the recent Qt beta. Seems pretty cool. I don't know if I will be
able to use Arthur for painting to images, tho. Too many things use pixmaps,
most notably brushes. This would make an image backend, something I want to
eventually do, inefficent (lots of pixmap<->image conversion).

We do have a couple libart-based painting classes, mostly for the SVG
applications. It would be interesting to look into doing a more complete one
with all of Arthur's features, (coordinate transformations, paths, etc...).
If I did this it would probably work on both QImage and MImage.

Right now I got to finish the MImage encoders. This will be most of the work I
have to finish before the first alpha.

[Dirk Schönberger]

> I also got the recent Qt beta. Seems pretty cool. I don't know if I will
be
> able to use Arthur for painting to images, tho. Too many things use
pixmaps,
> most notably brushes. This would make an image backend, something I want
to
> eventually do, inefficent (lots of pixmap<->image conversion).

You could implement an own paint engine for Arthur which works on a QImage /
memory buffer.
I think you really need the QPixmaps for e.g. brushes, because they are
separate data from the actual render target.

You can find another attempt for a rendering API based on QPainter in my
KPainter API in kdenonbeta.
This already contains a buffer / libart based backend and a backend which
uses QPainter.
Other interesting backends would include a Arthur based backend or a Cairo
based backend.

My API doesn't use so much QPixmaps, instead it uses a more "declarative"
approach to e.g. describing gradients.

> We do have a couple libart-based painting classes, mostly for the SVG
> applications. It would be interesting to look into doing a more complete
one
> with all of Arthur's features, (coordinate transformations, paths,
etc...).
> If I did this it would probably work on both QImage and MImage.

KPainter is similar to the Karbon 14 rendering engine, but it provides
multiple possible backends.
The other attempts I have seen are mostly directly coupled to a lowlevel
rendering library like AGG or libart.

Regards
Dirk

[Hans Oischinger-2]

On Monday 03 January 2005 16:16, Dirk Sch?nberger wrote:
> The other attempts I have seen are mostly directly coupled to a lowlevel
> rendering library like AGG or libart.
KCanvas in kdenonbeta also provides multiple targets and is already quite
functional.

Greets,
 Hans
--
Hans Oischinger ho@... | hans.oischinger@...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20050103/e877c2ad/attachment.pgp

[Mosfet-2]

I haven't looked at kcanvas or kpainter much, I just got KDE CVS going and
didn't co kdenonbeta yet. I'll definitely have a look. I mostly just looked
at the SVG stuff and Karbon. My earlier attempts at MosfetPaint had a painter
based on the svg icon painter ;-)

The main problem with doing an Arthur backend for images is, as I said, the
brushes. Pixmapped brushes will suck because they are pixmaps, not images.
This means they are on the X server in whatever the server depth is. Not only
does this mean you need to convert the pixmap to an image before using them
on your own image, (bad performance), but it will be truncated or dithered if
your display is not truecolor, (ie 16bpp). That is the biggest problem IMHO.
You can always cache pixmaps as images in your canvas backend to increase
performance, but if the X server is running at 15 or 16bpp your going to lose
color resolution. If you guys are old school you'll remember XPaint always
warning about this ;-)

You'd want a brush class that has it's own image, not an X pixmap. Fonts are
another problem, too...

As for being directly coupled to something like libart, I don't see much
problem with that. Libart is really useful. Who wants to recode all those AA
graphics and path stuff? Not me ;-) As long as it's toolkit independent and
can handle normal BGRA scanlines, (which it can), I'm happy.


On Monday 03 January 2005 09:26 am, Hans Oischinger wrote:
> On Monday 03 January 2005 16:16, Dirk Sch?nberger wrote:
> > The other attempts I have seen are mostly directly coupled to a lowlevel
> > rendering library like AGG or libart.
>
> KCanvas in kdenonbeta also provides multiple targets and is already quite
> functional.
>
> Greets,
>  Hans

[Dirk Schönberger]

> The main problem with doing an Arthur backend for images is, as I said,
the
> brushes. Pixmapped brushes will suck because they are pixmaps, not images.
> This means they are on the X server in whatever the server depth is. Not
only
> does this mean you need to convert the pixmap to an image before using
them
> on your own image, (bad performance), but it will be truncated or dithered
if
> your display is not truecolor, (ie 16bpp). That is the biggest problem
IMHO.

This mean you cannot be sure that your QPixmaps are at least RGB / 24 bit
deep, irregardless of the X server you use.
Didn't know this. Ouch!

> As for being directly coupled to something like libart, I don't see much
> problem with that. Libart is really useful. Who wants to recode all those
AA
> graphics and path stuff?

The problem with a direct coupling to libart is that you are limited to
buffer based rendering.
No way to e.g. create PDFs or print to a printer, or you may want hardware
acceleration, or...
This may be enoug for a rendering API which is only used internally in a
paint app, but already for a vector graphics editor
and even more for a general purpose rendering API it is definitly useless.

Regards
Dirk

[Dirk Schönberger]

> > The other attempts I have seen are mostly directly coupled to a lowlevel
> > rendering library like AGG or libart.
> KCanvas in kdenonbeta also provides multiple targets and is already quite
> functional.

Ok, you are right.

KCanvas is designed for "retained mode" graphics, i.e you keep a tree (or
list) of graphical objects you can manipulate, which render themselves.
KPainter is designed as a rendering API only, i.e. after you call "end" on
it, you may not change it anly longer.
This still means you may have cached backends, i.e. the rendering primitives
can be rendered to a buffer, and at the end the
buffer is rendered to the target device.
In theory you could implement KCanvas with a KPainter backend, but KCanvas
contains some optimizations for partial updates
which make this less than feasible.

Regards
Dirk

[Mosfet-2]

I believe I see what you mean: you want to be able to have different backends
so you can print to PS, PDF, etc... ie: what Arthur should allow. It's okay
to use libart for images, but you want to have non-image destination devices.

In this case it would be best to do an Arthur backend but I really don't see
this as a good solution. It's too tied to X11 pixmaps and drawables. All the
pixmaps used in things like brushes are the most obvious, but QFont is a
problem too if you want to render text directly to the image.

Basically, in my ideal world I would be looking for this: I first believe
people will want to use pattern lines and fills so I would want good image
brushes. Not pixmaps. I would also like to have the text rendered directly to
a BGRA or RGBA image. This would mean using freetype directly, (there is a
lot of example code for this all over the place), and possibly t1lib.

With all that work already there is no way I'm not going to utilize libart...
That is if I do a painter at all - I'm just throwing ideas around ;-)

I looked around for the Arthur PostScript backend and wasn't able to find it.
Do any of you know what file it's in or if it's complete? I kind of figured
that if I kept the API similiar you'd be able to use the new painter for your
images and Arthur for printing, PS, and PDF. I just don't believe I can use
Arthur for images for the reasons I mentioned. I would prefer if I could.

On Monday 03 January 2005 02:28 pm, Dirk Sch?nberger wrote:
...snip...

>
> The problem with a direct coupling to libart is that you are limited to
> buffer based rendering.
> No way to e.g. create PDFs or print to a printer, or you may want hardware
> acceleration, or...
> This may be enoug for a rendering API which is only used internally in a
> paint app, but already for a vector graphics editor
> and even more for a general purpose rendering API it is definitly useless.
>
> Regards
> Dirk
>
>
>
>
>
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

[Mosfet-2]

No, you cannot depend on pixmaps being any particular depth. Right now on my
machine it's not 24bpp, and I'm running a brand new X.org CVS checkout.

I use a 16bpp video mode with LSB byte order, so that's what pixmaps are.
Pixmaps will always have the same color depth as the visual you are using.

A lot of non-X11 geeks don't realize what happens when you convert an image to
a pixmap. No matter if your using Qt, MImage, ImageMagick, or Imlib you first
convert the toolkit's image into an XImage. An XImage is a scanline-based
image but is in the byte order and depth of the X server's visual. This means
if the X server is 16bpp the XImage will be 16bpp or below.

Then you place the XImage on the server, preferably with MIT-SHM. What you get
back is a X11 pixmap handle to the image. X11 pixmaps are really only integer
ID's to an XImage on the X server. You can't directly access the scanlines
anymore. If you want to directly access the bits you need to copy the image
back to your client, (convert the pixmap to an image), but you have to
remember it's been truncated to whatever depth your X11 visual is.

That's why I don't like programs that convert an image to a pixmap to display
it, then convert it back to an image to edit it. You'll end up loosing color
resolution. You should keep the image around in your client and just convert
to pixmaps to display it.

On Monday 03 January 2005 02:28 pm, Dirk Sch?nberger wrote:
>
> This mean you cannot be sure that your QPixmaps are at least RGB / 24 bit
> deep, irregardless of the X server you use.
> Didn't know this. Ouch!

[Dirk Schönberger]

> I believe I see what you mean: you want to be able to have different
backends
> so you can print to PS, PDF, etc... ie: what Arthur should allow. It's
okay
> to use libart for images, but you want to have non-image destination
devices.

non-buffer devices, but otherwise, yes.

> In this case it would be best to do an Arthur backend but I really don't
see
> this as a good solution. It's too tied to X11 pixmaps and drawables. All
the
> pixmaps used in things like brushes are the most obvious, but QFont is a
> problem too if you want to render text directly to the image.

If you use the KPainter frontend, you don't really see the Arthur
implementtation details, at least so is the theory.
The primitives KPainter provides should be complete (otherwise the API
should be extended, not the implementation details made public)

> Basically, in my ideal world I would be looking for this: I first believe
> people will want to use pattern lines and fills so I would want good image
> brushes. Not pixmaps

If you are right with your assumption that in using QPixmaps I cannot
guarantee 24/32 bit flat image buffers without quality loss, I tend to
agree.
Basically I see the following fill types

- patterns, basically QImages, bitmapped data
- gradients, basically algorithms which describe how a path is filled.
Currently KPainter only contains SVG style linear and radial graients, but
it
  would be nice to have complex gradients (eg. Adobe Illustrator / PDF
gradient meshes)
- vector fill patterns - by a callback mechanism you can use rendering API
calls to fill a "container" path. Currently not really implemented
- hatches - a special kind of monocolour pattern which only contains out of
vertical or horizontal lines

> I would also like to have the text rendered directly to a BGRA or RGBA
image. This would mean using freetype directly, (there is a
> lot of example code for this all over the place), and possibly t1lib.

KPainter (or at least its libart backend), contains some code which uses
freetype to render text. This is just a proof of concept, I am not quite
happy with the current state. I think the text model is to simple (I would
need at least typographic and mass texts), and it is possible not Unicode /
I18N clean. Unfortunately Qt4's text engine is rather close coupled to
Athur, I think.

> With all that work already there is no way I'm not going to utilize
libart...
> That is if I do a painter at all - I'm just throwing ideas around ;-)

Nobody said you shouldn't. For a bitmap editing application a directly
accessible image buffer is a must, no doubt in that.

> I looked around for the Arthur PostScript backend and wasn't able to find
it.
> Do any of you know what file it's in or if it's complete?

I found a qpsprintengine_p.h and related files in beta 1, which should
contain the PS generator. I think in the Linux / Open Source version
printing is limited to Postscript generation. I haven't looked about its
capabilities, yet (basically, Postscript is not able to render opacity,
transparency effects correctly, so there may be some limitation in its use)

> I kind of figured
> that if I kept the API similiar you'd be able to use the new painter for
your
> images and Arthur for printing, PS, and PDF. I just don't believe I can
use
> Arthur for images for the reasons I mentioned. I would prefer if I could.

Unfortunately I differ in some design decisions from Arthur. I would like to
implement a state based rendering API similar to Postscript, while in Arthur
the render state is rather limited. So there are some major differences
between Arthur and KPainter, I think.
The public frontend API should be similar, at least on the level of Qt3's
painter.
It should be possible to implement a Arthur based backend KPainter, I am not
so sure about the opposite.

But for now KPainter is in hibernate mode, because it currently has no
users...

Regards
Dirk

[Lars Knoll]

On Monday 03 January 2005 18:01, Mosfet wrote:

> I haven't looked at kcanvas or kpainter much, I just got KDE CVS going and
> didn't co kdenonbeta yet. I'll definitely have a look. I mostly just looked
> at the SVG stuff and Karbon. My earlier attempts at MosfetPaint had a
> painter based on the svg icon painter ;-)
>
> The main problem with doing an Arthur backend for images is, as I said, the
> brushes. Pixmapped brushes will suck because they are pixmaps, not images.
> This means they are on the X server in whatever the server depth is. Not
> only does this mean you need to convert the pixmap to an image before using
> them on your own image, (bad performance), but it will be truncated or
> dithered if your display is not truecolor, (ie 16bpp). That is the biggest
> problem IMHO. You can always cache pixmaps as images in your canvas backend
> to increase performance, but if the X server is running at 15 or 16bpp your
> going to lose color resolution. If you guys are old school you'll remember
> XPaint always warning about this ;-)

True. I've forwarded this to the arthur maintainers for consideration. Adding
image based brushes shouldn't be too difficult.

> You'd want a brush class that has it's own image, not an X pixmap. Fonts
> are another problem, too...

Mostly solved in arthur. You can convert a rendered text string into a path
that you can then use for drawing on your surface. Currently this only works
for outline fonts, but we'll add support for bitmap fonts before 4.0.

> As for being directly coupled to something like libart, I don't see much
> problem with that. Libart is really useful. Who wants to recode all those
> AA graphics and path stuff? Not me ;-) As long as it's toolkit independent
> and can handle normal BGRA scanlines, (which it can), I'm happy.

Just as a sidenote: I'm reading this list and trying to forward relevant stuff
to the arthur maintainers, but if there is stuff you need in arthur for Qt 4,
it would be great if you could send mail to
qt4-preview-feedback@....

Cheers,
Lars

[Lars Knoll]

On Monday 03 January 2005 23:56, Mosfet wrote:

> I believe I see what you mean: you want to be able to have different
> backends so you can print to PS, PDF, etc... ie: what Arthur should allow.
> It's okay to use libart for images, but you want to have non-image
> destination devices.
>
> In this case it would be best to do an Arthur backend but I really don't
> see this as a good solution. It's too tied to X11 pixmaps and drawables.
> All the pixmaps used in things like brushes are the most obvious, but QFont
> is a problem too if you want to render text directly to the image.
>
> Basically, in my ideal world I would be looking for this: I first believe
> people will want to use pattern lines and fills so I would want good image
> brushes. Not pixmaps. I would also like to have the text rendered directly
> to a BGRA or RGBA image. This would mean using freetype directly, (there is
> a lot of example code for this all over the place), and possibly t1lib.
>
> With all that work already there is no way I'm not going to utilize
> libart... That is if I do a painter at all - I'm just throwing ideas around
> ;-)
>
> I looked around for the Arthur PostScript backend and wasn't able to find
> it. Do any of you know what file it's in or if it's complete? I kind of
> figured that if I kept the API similiar you'd be able to use the new
> painter for your images and Arthur for printing, PS, and PDF. I just don't
> believe I can use Arthur for images for the reasons I mentioned. I would
> prefer if I could.

Once again: Then tell us what you need. Without hearing from you our arthur
maintainers can't know about your needs :)

Cheers,
Lars

[Lars Knoll]

On Tuesday 04 January 2005 00:17, Mosfet wrote:

> No, you cannot depend on pixmaps being any particular depth. Right now on
> my machine it's not 24bpp, and I'm running a brand new X.org CVS checkout.
>
> I use a 16bpp video mode with LSB byte order, so that's what pixmaps are.
> Pixmaps will always have the same color depth as the visual you are using.
>
> A lot of non-X11 geeks don't realize what happens when you convert an image
> to a pixmap. No matter if your using Qt, MImage, ImageMagick, or Imlib you
> first convert the toolkit's image into an XImage. An XImage is a
> scanline-based image but is in the byte order and depth of the X server's
> visual. This means if the X server is 16bpp the XImage will be 16bpp or
> below.
>
> Then you place the XImage on the server, preferably with MIT-SHM. What you
> get back is a X11 pixmap handle to the image. X11 pixmaps are really only
> integer ID's to an XImage on the X server. You can't directly access the
> scanlines anymore. If you want to directly access the bits you need to copy
> the image back to your client, (convert the pixmap to an image), but you
> have to remember it's been truncated to whatever depth your X11 visual is.
>
> That's why I don't like programs that convert an image to a pixmap to
> display it, then convert it back to an image to edit it. You'll end up
> loosing color resolution. You should keep the image around in your client
> and just convert to pixmaps to display it.

For high quality graphics apps this is correct. However for at least 95% of
the use cases you don't care about the source image anymore and it would just
be a memory hog on the client side.

Qt is about making things as easy as possible for the 95% of the use cases and
making the other 5% possible, so it would IMO be a mistake to cache the
source image in general. Also as soon as someone opens a painter on the
pixmap, you'd have to throw away the source anyways.

Cheers,
Lars

[Mosfet-2]

On Tuesday 04 January 2005 03:59 am, Lars Knoll wrote:
...snip..
> > your canvas backend to increase performance, but if the X server is
> > running at 15 or 16bpp your going to lose color resolution. If you guys
> > are old school you'll remember XPaint always warning about this ;-)
>
> True. I've forwarded this to the arthur maintainers for consideration.
> Adding image based brushes shouldn't be too difficult.
>

Hi Lars! It's been a long time. Nice to see you on the list :)

That would certainly be cool.

> > You'd want a brush class that has it's own image, not an X pixmap. Fonts
> > are another problem, too...
>
> Mostly solved in arthur. You can convert a rendered text string into a path
> that you can then use for drawing on your surface. Currently this only
> works for outline fonts, but we'll add support for bitmap fonts before 4.0.
>

To be honest I didn't notice that. Good deal. Drawing text on images was a big
problem on Qt3.x.

...snip...
>
> Just as a sidenote: I'm reading this list and trying to forward relevant
> stuff to the arthur maintainers, but if there is stuff you need in arthur
> for Qt 4, it would be great if you could send mail to
> qt4-preview-feedback@....
>

I'll join today or tomorrow.

> Cheers,
> Lars
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

[Mosfet-2]

On Tuesday 04 January 2005 04:07 am, Lars Knoll wrote:
> On Tuesday 04 January 2005 00:17, Mosfet wrote:
...snip...

> >
> > That's why I don't like programs that convert an image to a pixmap to
> > display it, then convert it back to an image to edit it. You'll end up
> > loosing color resolution. You should keep the image around in your client
> > and just convert to pixmaps to display it.
>
> For high quality graphics apps this is correct. However for at least 95% of
> the use cases you don't care about the source image anymore and it would
> just be a memory hog on the client side.
>

Well, there are people doing it in paint apps and such ;-) I think this is
largely due to a lack of a painter for QImage.

> Qt is about making things as easy as possible for the 95% of the use cases
> and making the other 5% possible, so it would IMO be a mistake to cache the
> source image in general. Also as soon as someone opens a painter on the
> pixmap, you'd have to throw away the source anyways.
>

I'm not suggesting you cache the QImage in QPixmap or anything. I'm suggesting
developers know what's going on and that you loose color resolution when
converting from image to pixmap then back again.

> Cheers,
> Lars
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

[Lars Knoll]

Hi Mosfet,

On Tuesday 04 January 2005 12:29, Mosfet wrote:

> On Tuesday 04 January 2005 03:59 am, Lars Knoll wrote:
> ...snip..
>
> > > your canvas backend to increase performance, but if the X server is
> > > running at 15 or 16bpp your going to lose color resolution. If you guys
> > > are old school you'll remember XPaint always warning about this ;-)
> >
> > True. I've forwarded this to the arthur maintainers for consideration.
> > Adding image based brushes shouldn't be too difficult.
>
> Hi Lars! It's been a long time. Nice to see you on the list :)

thanks. It's good hearing of you again as well :)

> That would certainly be cool.
>
> > > You'd want a brush class that has it's own image, not an X pixmap.
> > > Fonts are another problem, too...
> >
> > Mostly solved in arthur. You can convert a rendered text string into a
> > path that you can then use for drawing on your surface. Currently this
> > only works for outline fonts, but we'll add support for bitmap fonts
> > before 4.0.
>
> To be honest I didn't notice that. Good deal. Drawing text on images was a
> big problem on Qt3.x.

I know. I've just seen the conversion to paths work with bitmap fonts as well
today (only on Windows for now, but the X11 version will follow soon). So
this is definitively solved for 4.0 :)

Btw, we are thinking about a paintengine for images, but this is something we
won't have in 4.0. There are too many other things to do first.

I've noticed that in some other mail you've spoken about performance issues in
QImage (scaling etc). I'd be happy to add optimised code for these things to
Qt if you've got any that you are willing to contribute :)

Cheers,
Lars

[Sven Langkamp]

Am Montag, 27. Dezember 2004 14:30 schrieb Mosfet:

> I decided to just try to finish up the first alpha of libmimage instead of
> doing a bunch of backporting. That way people can test the code I actually
> use then I can backport to KDE once. Seems to make more sense.
>
> For people who are wondering, this is what I want to work on in order of
> release:
>
> 1) libmimage
> 2) The MIMS photo browser, (the successor to PixiePlus). Chris Howells is
> currently maintaining the old version of PixiePlus in kdenonbeta and knows
> about the new one.
> 3) libmultilayer (64bit tiled, layered image library)
> 4) MIMS Paint

Did you take a look on Krita? It adresses at least 3 and 4. It stores the
image internally in a tile manager and has it's own painter/paintdevice.

[Mosfet-2]

I've settled on the Imlib2 smoothscale algorithm. It's BSD licensed, produces
good output, and the MMX version runs in about 1/6th the time of Qt.

I also did a quick inline MMX version of the Qt algorithm that ran in about
1/2 the time, but that is nowhere as fast as the Imlib one and required
3dnow! Not as good.

My plan right now is to release an MImage alpha, hopefully people will test
it, then backport the effects (including the scaling), to KImageEffect. If
you guys want to snag anything MImage, Imlib2, and KImageEffect are all BSD
licensed.

I did a quick tarball awhile ago of effects ported from MImage to QImage but
didn't get a whole lot of feedback. Now I am just focusing on getting MImage
released. It's mostly just image encoders, (the decoders are finished), and
dithering I have to finish.

On Tuesday 04 January 2005 06:07 am, Lars Knoll wrote:
...snip...

> > To be honest I didn't notice that. Good deal. Drawing text on images was
> > a big problem on Qt3.x.
>
> I know. I've just seen the conversion to paths work with bitmap fonts as
> well today (only on Windows for now, but the X11 version will follow soon).
> So this is definitively solved for 4.0 :)
>
> Btw, we are thinking about a paintengine for images, but this is something
> we won't have in 4.0. There are too many other things to do first.
>
> I've noticed that in some other mail you've spoken about performance issues
> in QImage (scaling etc). I'd be happy to add optimised code for these
> things to Qt if you've got any that you are willing to contribute :)
>
> Cheers,
> Lars
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

[Mosfet-2]

Yep, and I talked with Boudewijn Rempt about it as well. We decided to share
code and discuss implementation details, but my code is much more lowlevel
than Krita's. I don't have much time, but here are the basic differences:

My tiles are 64bit RGBA, accessing them is done internally with bitshifts,
etc... The API for a layer is very similiar to a QImage with 16bit pixel
components and a few extra things for tiles. Krita on the other hand has a
much more sophisticated pixel and color representation. Mine is very fast and
will be easy for people to pick up. Krita's is much more sophisticated, but
well, slow and not so easy, (no offense intended here - it aims to do a lot
more than I do).

When Krita resumed development I had to decide what I was going to do with
MosfetPaint, (and multilayer). I decided the Krita people would probably do a
better job doing a painting app and tools. I'm a pretty lowlevel type of guy.
I would probably do a better job doing a fast multilayered raster image
implementation. So I believe we basically decided to keep doing what we are
doing but keep in touch. When the multilayer library is finished there will
be a lot more communication between myself and Krita developers.

MosfetPaint in my documentation isn't even called "MosfetPaint" anymore. It is
the "MIMS Photo Editor" and will be more for applying filters on multiple
layers. I may not even stick with 64bpp. I may instead decide to do make
MImage optionally use tiles, do a layer management class, and write a
viewport widget to render it. That way I can use all the optimized effects
and filters and whatever painter class we end up with.

So as you can see I'm going more for "how do I get multiple layers rendered as
fast as possible?" than "How do I write a Photoshop". This doesn't mean there
can't be sharing of ideas. Specifically tile management and selections have
come up. But the goals are quite different.

On Tuesday 04 January 2005 08:39 am, Sven Langkamp wrote:

> Am Montag, 27. Dezember 2004 14:30 schrieb Mosfet:
> > I decided to just try to finish up the first alpha of libmimage instead
> > of doing a bunch of backporting. That way people can test the code I
> > actually use then I can backport to KDE once. Seems to make more sense.
> >
> > For people who are wondering, this is what I want to work on in order of
> > release:
> >
> > 1) libmimage
> > 2) The MIMS photo browser, (the successor to PixiePlus). Chris Howells is
> > currently maintaining the old version of PixiePlus in kdenonbeta and
> > knows about the new one.
> > 3) libmultilayer (64bit tiled, layered image library)
> > 4) MIMS Paint
>
> Did you take a look on Krita? It adresses at least 3 and 4. It stores the
> image internally in a tile manager and has it's own painter/paintdevice.
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

On Tuesday 04 January 2005 16:28, Mosfet wrote:

> So as you can see I'm going more for "how do I get multiple layers rendered
> as fast as possible?" than "How do I write a Photoshop". This doesn't mean
> there can't be sharing of ideas. Specifically tile management and
> selections have come up. But the goals are quite different.

The code Mosfet has shown me makes a lot of things about paint apps quite a
bit clearer to me. And I'm reading this list, and learning more. In other
news, I've just put up a first binary 'release' (just an apbuild built cvs
snapshot) of Krita :-) for the world to see.

--
Boudewijn Rempt
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20050104/9bf01973/attachment.pgp