[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    YAKU (Yet another Krayon update)
From:       John Califf <jcaliff () compuzone ! net>
Date:       2000-11-16 17:23:55
[Download RAW message or body]

"Today I am this way, tomorrow I am that way. My condition is very
unstable" - Hafiz

Some of you may be wondering what happened to the latest Krayon update.
So, I decided to start a new thread to let you know.  Nothing has been
committed to cvs yet since my last commit a month or so ago. I had to
make some decisions first.  First one way, then the other.  Now I have
made a pretty firm decision about which way to go.  If anyone objects,
please speak up now.

About 10 days ago I finished up a lot of Krayon essentials like loading
and saving in the native .kis format and exporting to the common image
formats like jpg and png.  It worked beautifully.  Then I started
thinking about how to add tools.  Krayon really had just one drawing
tool - drawing with a monochrome brush.  The other tools were variations
on this or were nonfunctional when I started - most still are.  Well,
the move layer tool worked and the area select outlined the area - a
start. 

The situation is this.  Krayon does NOT use the normal QPixmap and
QImage and QPainter classes for its drawing and image processing. 
Instead, it uses custom classes and routines, all written at a low
level.  Essentially, it's binary reading and writing of scan lines in a
format similar to, but not exactly like, QImage.  But these scan lines
are broken up by a number of tiles, which are updated with a timer
which runs continuously.  Sounds complicated, and it is. Another
difference is that Krayon access binary data by channel, like RGBA.  One
for each color, basically. This is well encapsulated and you can access
the data in terms of x,y coordinates and translate to QImage and QPixmap
formats, regardless of the tiles, but writing TO the data using Qt is
nearly impossible.  Each tile is like a piece of paper with writing on
it, wrapping lines.  And there are hundreds of such tiles for a large
image, like laying sheets of typewritten paper out on a desktop.  Scan
lines are within each tile, and do not run continuously across the
entire image as in almost every other image format.

So, I ifdefed out all the custom Krayon stuff and tried using common Qt
Classes with the app.  It worked - but that is not desirable in the long
run.  The advantage of the custom format is that it can handle 32 bit
binary image data exactly, and you operate directly on the data in terms
of channels per layer.  When it shows on the screen (the koffice canvas)
of course you are limited to your display resolution, usually 16 bit,
but you don't lose data or have to dither internally.  Further, Krayon
is capable of handling a variety of color types (ways of storing raw
data in channels) and can be extended to 64 bit later if needed.  Also,
layers are more easily handled, quickly and cleanly. Qt can't do that. 
You are limited to the depth of your dispay device using QPixmap and
while QImage is similar to Krayon's Image class the difference is the
tiles.  QImage uses continuous scan lines - Krayon's are broken up by
the tiles and further storage is at the channel level.  While the same
data can be translated back and forth between QImage and a Krayon Image,
it is not direct and uses custom routines which are difficult to
understand without giving it a lot of thought.

By the way, there was a bug caused by a simple typo in the channel.h 
header file that has probably been there forever. X size was returning
the Y size instead for channel memory.  This caused crashes whenever you
tried to open an image with the x dimension larger than the y
dimension, so sizes were hard coded to 512x512.  With that bug fixed,
you can now open any size image with the New dialog.  I am now very
confident that the Krayon custom code - the image system, is solid.  

A few days ago I took a break from all this complexity and worked on
KIconeditor and KPaint to learn more about tools. The problem with
Krayon tools is that they have to be coded at a low level - you CANNOT
use QPainter to draw lines, boxes, rectangles or even to blit. 
Fortunately, I discovered that KIconeditor has all the basic tools
already done using image data (scan lines) instead of higher level
calls.  So, much of that code can be used in Krayon with minor
adjustment to speed up creation of tools, which otherwise would take me
or most other programmers a very long time to create, whereas tools
using QPainter are much easier to code. Basic tools are line,
circle/ellipse, (rectangular) area select, move, fill, and brush.  All
other tools can be derived from these, I think.

As it now stands, I propose to ifdef all my Qt stuff back out and return
the original Krayon image system.  It now seems more doable.  This will
take a few more days.  Don't expect a lot of functionality except the
loading and saving and image export, which is very nice, though.  

I'd still like to get rid of the tiles, as I can't see how they speed
things up without also using the custom threads in Krayon, and the
threads are currently non-functional. Not using continuous scanlines
makes it difficult or impossible to use existing code from dozens of
other applications based on image scanlines which are continuous,
expecially with the update timer continuously running in the backgroud
changing things.  For the time being I'm leaving the tiles in, but I am
considering simplifying them away.  

For those looking for results, there have been several improvements to
the gui. You can now add multiple images within a document with the
tabs, and you can hide and show the sidebar now, allowing more room for
the image.  You can also open a new image with the New dialog specifying
size and other parameters, or open an existing image.

So, I will get back to undoing my latest changes and returning to the
custom Krayon image system, and then commit that for you to test.  I
think the pace of the work will pick up some but probably not in time
for a December release of Kde as I thought.  Once the basic tools are
built - line, circle/ellipse, brush, cut and paste tools, etc., then
perhaps these can be extended instead of having to access the data in
binary format (using hexadecimal) which most programmers don't want to
mess with these days.  It should be easier for others to add lots of
tools fairly efficiently.

Cheers, John
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]