Brush spacing / rotate / scale
achiestdragon at whipy.demon.co.uk
Fri Nov 16 13:14:00 CET 2007
On Friday 16 November 2007 11:22:53 Moritz Moeller wrote:
> Boudewijn Rempt wrote:
> > Computers still aren't really fast enough :-(. Both gegl and krita have
> > performance problems. Nobody has yet been able to do a nice watercolor
> > simulation realtime at a resolution of more than 1024x1024, and most only
> > give 512x512, not even with gpu acceleration or with beowulf clusters. A
> > complicating issue is that screens are getting bigger, so we need to
> > calculate waymore display pixels.
> That is simply not true.
> It all comes down to implementation. Even if an apps's brushes are dead
> slow (which probably means the implementation approach should be
> re-visited anyway):
> Who ever said you need to render a brush at the highest resolution while
> user is stroking?
> Who ever said you even need to render it at the resolution required for
> the current view while the user is stroking?
> If you have dynamic level of detail, you can just render the brush at
> the best resolution possible for the machine spec & zoom level at hand
> while the user is stroking. Once the user has released the pen, you
> render the currently required detail level. In the background you can
> start rendering the document's detail level (which might again be higher
> than the required detail level for the current view).
> Do all this multi-threaded, and I there's you can get very high quality
> brushes with real time responsiveness on today's boxes.
> I mean seriously: look at the level of detail today's games archive at
> 60+ FPS. Imagine compressing this detail into a brush stroke.
> Even the offline 3D high-end renderes we use in feature film VFX can
> render fully anti-aliased images at SD res, of several 100k
> micropolygons will a single lightsource and a plastic shader at full
> antialiasing at 3-4 fps on today's boxes.
> With Krita we are talking 2D. So there's a all kinds of cheats possible.
> You could e.g. implement brushes on the GPU, render them into textures,
> then use high-quality downsampling to get the required quality b4
> rendering them into the image.
> One of the (still) most expensive real time compositing systems, Flame,
> uses OpenGl to render almost everything (including final images), using
> this trick).
> If the approach is good enough for a 250k Euro BMW commercial, it sure
> is good enough for Krita. ;)
well tipicaly i work with images at about 3600*2900 ish
the screen aria of 1960*1240
when doing a brush stroke the following is needed
1 it needs to update the actual image
2 it needs to update the part of the image that is displayed on the screen
and scale the brush for that modification
if i was drawing using pencils the average short brush stroke = to about 1"
per second , would translate to 80 points that would need updating
( assuming working at 1 to 1 image on the screen )
first it needs to recode the stroke (and all the changes made during it so the
undo works )
so you got
1 calculate the brush path and intermediate points
2 calculate the actual info to change and log it
3 update the main image to a temp image
4 recalculate and scale that image
5 display it
now thats how i see it needs to be (it may not be that way and may have missed
but heres the problem
decoding a mp3 or 4 etc reads 1 stream from disc or ram
it can then decode that stream in the cpu cache
then it outputs that stream to the display buffer
although it may use a complex method to do that
you are not hitting the main problem
that is memory bottlenecks that you encounter trying to read and write
at multiple streams at the same time
even multithreading is going to have the same problem and if your hitting
swap space then you can forget real time updates
and all this before seperate layers are taken into account
but from the basic processing point of view 1 brush stroke would result in 8
to 9 times the data traffic than you would get just decoding a single mp4
even though the processing may not be as intense
but on that note it is posible on my machine to simultaniously play 9 avi
files at 640*480 all displayed in seperate visible windows before i start
to get dropped frames
so maybe theres some method that it could be speeded up
now on a brush stroke is the whole displayed image updated at each point
or is just the area affected updated
there should be no reason to update the whole displayed image if only a small
area of it has been changed
as long as the viewable area of the screen is not moved in the process
> kimageshop mailing list
> kimageshop at kde.org
More information about the kimageshop