Stephen McKeague wrote:

>> this of course triggers a big update of the spec. there are also some
>> rough edges in the spec that need to be defined: like when the  
>> frame is
>> partially in view, or no edge of the frame is in view.
> On this note, could you please clarify for me where it says, "Only  
> the visible part of the transform frame goes into the size  
> calculations".

with the "size calculations" I meant the calculation of all the  
handles for
manipulating the frame are done according to how big the transformation
frame is on-screen.

what needs sorting out is that after some manipulation the  
frame can be any kind of shape that can be made out of 4 corners  
by 4 straight lines, including a twisted bow tie type of shape.

this general shape is then clipped by the viewport of the image window,
which is really a rectangle. This clipped general shape then needs to
be manipulated. I still have to investigate what is reasonable for users
to be able to do in these situations and how I can make this happen.

> Also, can you please confirm why the transformation tool would only  
> perform the calculation when the user "goes and does something else".

yeah that passage is not clear. what I mean is that what is manipulated
on-screen is just a preview of the real image data: it is just a limited
amount of pixels (there are only 1 to 2 Mpix on a monitor) and it will,
using all the dirty tricks in the world, 'instantly' reflect the
transformation made by users using the handles. even while moving the  

the real transformation of the real pixels in memory is then done with
the aggregate transformation in one pass when "users go and do  
something else."
this is the "maximum fidelity contract" with users.


         founder + principal interaction architect
             man + machine interface works
 : on interaction architecture

Gimp-developer mailing list

Reply via email to