Hi, We are running SRSS 5.3 on Solaris 10 U 11 with CDE desktop and SR2/SR2FS/SR3 DTUs. Since upgrading from SRSS4.2 we have a spurious issue with a single legacy 3rd-party application GUI which is basically forms-based with fields which are filled by the application.
The text contents of these fields may change and all appears normal until the fields are covered by another window and then exposed again. Then bizarrely, what is displayed in each affected field is a super-imposition of all the text values that have been displayed in the field. It literally looks like an old-fashioned ribbon typewriter where words have been overtyped. Not all such fields are affected, but I have yet to determine how the attributes of a field affect the behaviour (we create the form definition files ourselves so I can experiment with the FDL code). The behaviour is seen when: 1) a window from any application is brought to front over the subject window by clicking on it, and then sent to back; 2) another window is dragged over the subject window without dropping, and then dragged away before dropping; or 3) the subject window itself is dragged so that its border passes over its affected field(s). Bear in mind that with (2) and (3), when dragging the window, only the window outline moves, so it is possible to see the super-imposed characters being revealed pixel-by-pixel as the outline passes over them. In fact it seems that it is the border edge-line causing the behaviour, because if a window is moved across very quickly, the over-painting is seen only partly or even not at all (probably due to long jumps in the cursor position updates). We have found that selecting Windows->Refresh from the CDE desktop menu, resets the behaviour: the fields show only the current contents, and the 3 actions above do not cause super-imposition any more. However if the contents change again the same behaviour occurs, combining just those content values that have been displayed since the Refresh. Similarly, resizing the affected window can cause it to be reset. Clearly there is some issue with repaint events going on. (In fact we have another symptom, probably related, where when a window is exposed after being partly covered, the background in that part may go, i.e. it is black instead of the background colour, until resizing etc). Thinking this may be some sort of graphics acceleration issue, I used utxconfig to disable XRENDER for the X-server, but it had no effect (after logging out and in). However, changing the X-server from Xnewt back to Xsun seems to completely eradicate the problem (which explains why we never saw it until we upgraded from SRSS 4.2 to 5.3). So while the legacy application probably has some contributing fault, it is also clearly dependent on the X-server. Questions: 1) Can anyone explain what is going on here - I really don't understand where/how some screen buffer is adding up the changes to these fields. Would it be in SRSS itself? 2) Is there any other workaround (or any ideas) that would mean we could stay with the recommended Xnewt? 3) I don't mind reverting to Xsun so long as we don't cause other problems. We don't do streaming video/audio or dynamic screen re-sizing or rotation, so are there any other important features/performance we would be missing out on? Is Xsun considered safe with SRSS 5? Are SunRay3's stable with Xsun? Thanks for any advice, Hugh
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
