Brush spacing / rotate / scale

[david powell]

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. ;)
>
> Cheers,
>
> Moritz

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 )

now 
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 
things )
 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

Dave


> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop