From kde-kimageshop Fri Nov 16 14:29:13 2007 From: Moritz Moeller Date: Fri, 16 Nov 2007 14:29:13 +0000 To: kde-kimageshop Subject: Re: Brush spacing / rotate / scale Message-Id: <473DA939.4010106 () dneg ! com> X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=119522340830192 david powell wrote: > well tipicaly i work with images at about 3600*2900 ish > the screen aria of 1960*1240 That's not even a high res. Eclipse/Satori could handle brushing on images of 10k*10k pixels in realtime on machines with 128 MB of RAM and much less CPU power than today a decade ago. > when doing a brush stroke the following is needed > > 1 it needs to update the actual image No it doesn't. > 2 it needs to update the part of the image that is displayed on the screen > and scale the brush for that modification Yes, but instead of scaling the brush, the brush should scale itself -- i.e. if it is a com,plex procedural brush, the system should tell the brush what detail level it needs/wants and the brush should do "less work" accordingly. > 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 That is the wrong approach. 1. Calculate visible portion (sub image) and level of detail aka LOD (zoom level) of current image 2. Calculate the brush path drawn by the user so far (intermediate points should be handled by the brush itself, not every brush might be working based on the old-school idea of cloning a bitmap over and over again along a path) 3. Calculate the visible portion of the brush stroke at the current resolution (zoom level) NOT at the image resolution 4. Render the brush into a buffer at the highest possible level of detail that is <= the needed LOD for the current zoom level that can still be computed in "realtime" on the user's system 5. Compose buffer over visible sub-image image at current resolution & display 6. If the LOD in step 4 was equal to the current LOD (i.e. the user's syetem was fast enough for the required LOD), add result to the tile cache; If not, re-render step 4 at the needed LOD and go to step 5. 7. Optionally, kick off a thread in the bg that renders the brush into the image at the images final LOD. The actual rendering of the brush into the full res image is *not needed* until the user either pans over the entire image at >=1:1 zoom or wants to save/print the image. Either is a very rare occurrence commonly. The approach you outlined misses too points: rendering at only the needed resolution and rendering with LOD. A procedural brush containing a fractal noise 6 octaves only needs those octaves rendered whose frequencies lies below the Nyquist limit for the current zoom level/LOD. Same goes for everything else. If you have a particle-based watercolor sim, the number of particles and their size can be adapted to the zoom level. You can offline the high quality sim to step 7 or even wait until the user actually zooms in or wants to save the image. .mm _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop