Community
Participate
Working Groups
I20040420 My system background colour is set to grey. Java editors in eclipse have a white background. When I switch between two editors, I see a flash to the grey system background colour. The grey is visible for a fair amount of time during the switch, and even longer if it is the first time I have accessed the file either in the current session or after it has been inactive for some time. The same behavior can be seen upon switching view tabs (easier to see when the view is maximized). A plausible reason for the flash may be that when we show the next widget, X initially fills the window to the background colour until the widget has a chance to draw itself.
Created attachment 9807 [details] Test app This archive includes a few test apps that try to mimic how CTabFolder works. It's not so conclusive: We get flashes switching pages of a GtkNotebook, but when I do code that tries to mimic how CTabFolder works, I don't see the flashes. I'm updating the test appliaction to draw the background colour instead of setting the system background colour on each window, and I suspect that will flash as well.
just to add add what may be a red herring, some views are much faster redrawing themselves and thus this annoying flash is not readily visible. for example, the new Intro view draws nice and quick, so any flash can't be seen. maybe we should look at how that view is rendered, and emulate it in others.
Alvin: The intro view sets the background of the entire widget (hence its GdkWindow) to white. The contents are still cleared to white then drawn to, but since the background is the same on all pages is white, you don't see a flash to grey. You can determine the background colour of the GdkWindows of each widget by playing with opaque resizing of windows before the contents have a chance to draw themselves. I don't know if it's feasible to have the entire editor area set its background colour to white, maybe there's an easier fix there that would make things that much smoother.
Bug 59707 addresses one problem relating to StyledText where the main text widget does not have the correct background colour. I hacked a fix here for this bug which makes alt-tab'ing to an occluded eclipse window look better, but does not solve the flash on tab switch. We may be able to fix the flash if we can figure out what widgets contain the styledtext and see if their background colours should be set differently, or if there is some reason they get mapped to the screen before the styledtext widget does.
I have a hack here that makes switching between editor tabs very smooth. It sets the background pixmap on the main StyledText widget to be NULL, and does the same to the ViewForm widget in PaneFolder in the UI's default presentation. The ViewForm contains the styledtext widget, and it is clearly visible on a switch to an inactive tab. I believe this shows we are hiding the old tab before showing the next one, which may be something we can fix. I do not believe that we can set this to have no background without causing problems, as it is visible behind view toolbars where the theme background pixmap should be applied. However, setting the background of the ViewForm to NULL does not completely solve the flash. The StyledText widget takes too long to draw, so its white background cleared before the text is visible. Setting the background pixmap on the styledtext to NULL has no side effects as the area is always completely drawn. There may be other widgets which could benefit from a NULL background pixmap, but as a start I think this may be a very useful fix.
Created attachment 10058 [details] NoBackground hack to Control/StyledText
Created attachment 10059 [details] NoBackground hack to PaneFolder's ViewForm
Adding Silenio and Steve to this discussion. I have tried the hack and found 1) That it didn't make that much of a difference - there is still some flash 2) We are relying on the underlying textured background to show through in CTabFolder and ViewForm. Adding gdk_window_set_back_pixmap(window, 0, false) causes black to be drawn instead of the desired texture. We are currently using gtk_rc_style_set_bg_pixmap_name to set the pixmap to "<none>" when a background colour is set. Not sure how this compares with gdk_window_set_back_pixmap. I think we should investigate how the workbench handles the selection of a tab since the StyledText widget is not actually a child of the CTabFolder. However, it should be noted that for OLE editors, it is mandatory that the old editor be deactivated before the new editor be created - in order to get the menubar activation correct. So the order may not be flexible.
The SWT.NO_BACKGROUND style is now honoured in GTK. Setting the background pixmap by calling gtk_rc_style_set_bg_pixmap_name() with "<none>" does not seem to work because of a bug in GTK. So we reset it by calling gdk_window_set_back_pixmap() every time it is needed. Making ViewForm a SWT.NO_BACKGROUND does not seem to be an option because of the theme manager. So I believe UI needs to change tab switching to show the new tab first and then hide the old one.
I do not understand why editors have a ViewForm inside them anyway. Is that a new requirement? Does eclipse ever put anything in the top slots of the ViewForm? If not, you could make parent of the editor be a Composite with the style SWT.NO_BACKGROUND. Another advantage of not using a ViewForm here is that the ViewForm does not accept any Layout set on it. Therefore, in order to put a layout on the contents, the application has to create yet another composite to be the parent. Instead of catering to the occasional editor that may wish to display itself in a ViewForm, why not let the editor choose to create a ViewForm if that is what it wants. I assume most editors do that anyway.
stefan, do we need to use a viewform for editors.... can we push that down?
Created attachment 10786 [details] Patch to change the order of setVisible calls on tab switch This patch changes the order which we make controls visible during a tab switch. It fixes the flashing between tab switches. I think this may be the correct solution.
Patch applied.
I have verified that this problem is fixed in I200405182000. Tab switching looks awesome.
