Re: Data flow analysis

  scrufffymydog@juno.com (Craig S. Ugoretz) schreibt:


>This would enable a user to click on a pixel on the screen and find
>out which object in the "child" application owns the pixel. Would
>data flow analysis be applicable to this type of problem? I am
>thinking that a piece of data may have to go through several
>transforms until it gets "stamped" upon the screen as a pixel.


What kind of "object" do you expect to find?


The pixels on a canvas depend on many "objects" or data. A pixel of a
character depends on all the font properties (objects), and all pixels
depend on the settings of viewports, scaling, clipping, colors
etc. The most basic "objects", responsible for the "physical" output,
reside in the runtime environment, inaccessible to analysis. Which of
those many objects do you want to retrieve? None, I suppose?


IMO you'll have to map the pixel coordinates from screen to "logical"
coordinates, from which you can determine the display object (screen
manager, component...) managing the output in that area of the
screen. In the next step you may want to determine the method call,
from application code to that object, that caused the last state
(color) change of the pixel. Remember that crossing lines and erasure
of the background can result in multiple changes to every single
pixel, and when the pixel happens to be in the desired state on
invocation of the drawing method, the call may terminate immediately,
with no detectable data flow from the application to the screen...


>In general, does anyone know if this type of problem has been
>attempted?


A general AND useful approach seems impossible to me, at least it
would result in a (huge) list of involved data sources. But if you
restrict the analysis to specific actions (method calls) to an set of
display objects, which you consider interesting or important, then you
can analyse the data flow from the application to those objects.


As a basic exercise you may write a function that determines whether a
concrete action can affect a given pixel, based on the object, method
or property, and arguments of the call. This may require special code
for every specific application, or an "interpreter" with a possibly
huge set of parameters for the emulation of applications in general.




I don't want to discourage you at all, but you may have seen that you
should add some more restrictions or conditions to your question. Or
you may find out that data flow analysis is not what you want to
do. For Windows I know of several tools that display the application
and window object under the mouse cursor, and the public properties of
that object. But these tools will fail to provide useful information
for all display objects which are under control of specific
applications, like Java. This may be the point where you want to jump
in, adding extensions that also can decode the architecture of screen
areas under Java management.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.