Re: [Visualoberon-win32] Port of XCal to new VO
Status: Beta
Brought to you by:
tteuling
From: Tim T. <ti...@ed...> - 2001-06-06 20:51:01
|
Hallo! > - Draw and HandleMouseEvent had to be significantly redone, but it was not > too hard. The greatest difference is that Blackbox mouse tracking is moda= l: > once a mouse press is detected the program must enter a polling loop to > read mouse motion events. Yes, I thought about that, too. I you not manually grab the mouse strange things may happen, becuase you may never get mouse up. So the core doing automatic mouse grabbing (that means, if a button down even accures delegate all mouse events to the object catching the button down even utnil he button gets raised again). This would make things simpler, but also less flexible :-/ > > There is also functionality for double buffering. So WireFrame for > > that. You just allocate a bitmap of the specified size, draw into it > > (the bitmap has a DrawInfo instance) and then copy it back to the > > window. This will avoid flickerr even more. > Both previous versions had this feature, but I haven't implemented it here > yet. It would be easy to implement, so I thought I should mention it. But it is = of course not needed. > > yet). It seems like already deep into VO :-) IF you have any comments > > regarding implementation details, nice or not that nice stuff, feel > > free to speak. > Here are a few initial comments that come to mind. > 1) The semantics of Draw are rather complicated. If I understand it > correctly, Draw may be called on a region that does not actually include > the object. It may also be called when the object does not need to draw > itself (visible=3DFALSE). The object needs to translate all coordinates to Correct. I thought about enforcing certain action. I could easyly implement a wrapper to Draw that does automatically create a clipping region for example. But that would not work if drawing is complicated. If you have a complex visualisation or can get certain different changes from you model you want to use special redrawing/refreshing methods. Draw() does not get called then. It would be up to the user, to call special DrawStart and DrawEnd methods implemented in the base class. Also Clipping is expensive and can slow down drawing. That is because I do not use subwindows for each control (Windows and X11 do support this). Using subwindows would save me from doing manually clipping. > its own x,y position and ensure that it does not draw outside its own > bounds. That is independent of the above and could always be implemented. However since we currently do not subwindows the translation would still be need - only just the other way round. This would include transformation for every drawing primitive. We could add two more additional variables (rX and rY, where "r" stands for "relative") that get updated after every call to Move. You see this rises and falls with the use of subwindows. It was a design decision to not use them, bceause at that point not all OSs I had in mind supported subwindows (Amiga OS for example). Since X11 and Windows are currentrly the only tragets (with Mac of course, too) this decision may have to be reevaluated. However moving in that direction would not be simple. We have to check if this has inpact on the event handling. We may get speed improvements in some parts (likly refreshing would be much faster) but some things may slow down (if subwindow clipping has an impact on the speed of drawing primitives). > Under Blackbox a Frame is a rider on a Port; the Port encapsuates the > actual OS device handle. The Restore procedure is passed a Frame which has > a zero origin and automatically translates the coordinates of draw > operations. It also has the clip region already installed, so that an > object cannot draw outside its own bounds. AWT does something similar. Th= is > makes client code simpler and less error prone. I prefer this approach. I > guess there may be a small performance penalty. The problem is that all refreshing goes throw one methods making this method much more complicated, especially when drawing is complex (think of atext widgets). > VO allows user code to call Draw directly. I don't have a problem with [...] Correct. It is not good and bad. Both aproaches have advantages and disadvatanges. I have no problem with changing that but it is a lot of work and I don't think, I want to do that on my own. > 2) I expected to be able to PushFont(f : Font), but there seem to be two > different types of font handle (Font and id). Do I have to store them bot= h? Possibly. Look at VO:Text.Mod for the use of that. You only need the ID for pushing and popping the font for drawing. However you need an instance of the font class for font specific operations like getting the size of a string when drawing it using this font. Font handling is not optimal (thats because X11 is rather compklicated in that respect). I'm not that happy with that part of the interface (OK, in fact every part could be a possible candidate for improvement ;-)) and I'm also willing to change that if there are suitable suggestions or even code. > 3) VO has DrawArc and FillArc. It has FillRectangle and FillPolygon. For > symmetry, there should probably be DrawRectangle and DrawPolygon. It might True. Fillrectangle and FillPolygon are missing, because I never used them <:-) also IMHO they are not part of the X11 drawing primitives. But they can be implemented using existing routines. If an OS has special support for them we could these optimized routines... NO problem with that. > also be nice to have DrawEllipse / FillEllipse, although I notice that > DrawArc calls the GDI Ellipse code when it gets 0..360*64. Yes, the X11 function is very powerfull (but has a strange interface IMHO). We could split that into separate methods so implementation on other OSs would be simpler. Thats is also an aproach that would help solve the colored pattern and dotted lines problems under Windows. > 4) It looks like Prefs are used for setting global parameters that control > the way a class of objects is displayed. It would be nice if this could > also be used to control local (per-object) preferences. For example, a > pop-up menu for an object could use a Prefs-style dialog to control the > look of that particular object. Is possible. There is for each object (in theory, in practice for most objects) a global prefs instance. Its values are read from the XML configuration file if file and values are accessible. If no internal defaults are used (that currently try to be close to Windows/KDE/Gnome). If you instanciate an object it uses that global instance for its own preferences settings. However you can instanciate other instances of that preferences object and fill it with you own values and then assign it to your special object instance (I never realy used that but it should work). So you can have preferences not only globale but also on an per instance basis. However, you should never use this, because you kill the look and the result perhaps may even not readable... > The previous version of my GraphView object used Blackbox Properties [...] I'm not sure I that above fullfills your needs. Do you have something different in mind? > Since VO uses LONGINT coordinates, it would make sense if PointDesc.x, y > were also LONGINT. This means that point arrays may have to be translated > for some implementations (X11?). Yes. But I would like to avoid allocating memory for calling drawing primitives or do some copying of data. Perhaps The methods should allocate a buffer with a defined size so you cannot assign array that are longer than his buffer. That way you would not need to allocate new memory but can copy (second best solution)...? -- Gru=DF... Tim. |