Brush spacing / rotate / scale

[Moritz Moeller]

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