Thursday, April 17, 2008

Screen Refresh Problems in Eclipse RCP Solved!

On my current project I was having some serious problems with screen refresh and I finally found a work around. The problem was I have a 4 pane perspective setup with 4+ views. The left half of the application area is a PDF viewer. When a user (me doing testing) would open a new PDF the fragments of the filedialog would remain overlayed during opening of the new PDF as well as the other views shifting over into the PDF area. The reason is because I had to do a HideView then ShowView. If I just did a close/open document function call in my swing PDF component the pdf component (I use icesoft IcePDF) would not always work. I am pretty sure this is due to the SWT to AWT bridge I have to do. So now here is the code to fix it!

Shell shell;
shell = getSite().getShell();
PDFView view = (PDFView)getSite().getPage().findView(PDFView.ID);
getSite().getPage().hideView(view);
shell.update();

Just doing a shell update seemed to do the trick, you may want to also look at this code if the above does not work for you. Look at the comments out code and it may be useful to you.

Shell shell;
shell = getSite().getShell();
// Display display = shell.getDisplay();
// Point shellSize = shell.getSize();
// shell.redraw(0,0,shellSize.x,shellSize.y,true);
PDFView view = (PDFView)getSite().getPage().findView(PDFView.ID);
getSite().getPage().hideView(view);
shell.update();
// display.update();

15 comments:

confuzzled said...

Hi Glenn!

This is amazing :) I never expected to find a way out of the refresh and flicker issue due to SWT_AWT technology! I would be trying out your suggested code for shell update. But just one quick confirmation, this code is sitting in your view definition class right?

Thanks a bunch for sharing such useful information!

Unknown said...

Hi Rahul,

I am at home now so can't verify where I placed the code. Will try to remember to check at work tomorrow. For me it was opening different PDF's so it very well could have been outside the view class.

It was definitely not in the PDFView class, which is the class I had the problems with. You should be able to execute this code from any class besides the View class you are having the problems with.

confuzzled said...

Ok. Thanks! You can drop a mail to me instead.. Also, the solution you have obtained resolves the frequent flickering issue? I'll check your blog for your replies anyway if you don't mail!

Unknown said...

I just checked where I put the code and it *is* in the PDFView class. It's in a LoadNewPDF function.

I like to post here because if others come along and find similar problems our discussion may help them.

As for your flickering. Can you go into more detail on what the problem is? When does the flickering occur? In a view with an SWT AWT bridge or not? Etc. Need more details. I did not really experience flickering. My problem was really it would not refresh the view properly and I am pretty sure it is a bug in the AWT<-->SWT bridge for my particular swing component (PDF) I implemented.

confuzzled said...

Hi Glenn!

I missed checking back here! :) That's interesting if you are placing the code in your view definition class itself (though I think it can sit outside too). Now in my case, I am using SWT AWT for 3 views in my custom perspective. Further, the problem I am really encountering is that these views do not get updated/refreshed when the internal AWT frame is refreshed. So I need to a hideView and showView to make them display the right contents. As a result of this hideView/showView there is a lot of flickering which happens and that is where I am looking for a solution! Anything you suggest could be really beneficial.

Thanks!

Unknown said...

The flickering you are seeing from hideview/showview is an artifact of the fact the window is being closed/destroyed and all the other windows move to fill the space/void of the now hidden window.

There are work a rounds to this that may or may not work.

Here is something to try:



1. Make your views into a tab placeholder for a new folder view (with only one placeholder view).
2. I think hiding and showing views as a tab on a folder will produce far less change in the layout of the screen.
3. The screen space allocated to the folder should remain constant. You may see a background area replace the view area for a few milliseconds.

You can test my theory out by doing a HIDEVIEW but NO SHOWVIEW. Just comment out the show view. Do all the windows re-size to fill the void?

You need to get it so this does not happen and the flicker will be nearly 100% gone.

Please post and let me know!

confuzzled said...

Thanks again for a prompt response. I'll try this out tomorrow and post back on the results. This does sounds like something that will resolve some of the flickering...

confuzzled said...

Hi Glenn! I tried what you suggested but again am not sure I interpreted exactly what you intended. Did you suggest using IPlaceholderFolderLayout for each of my view and adding the associated view for each IPlaceholderFolderLayout as a PlaceHolder? Or did you suggest using IFolderLayouts and adding each view as a single view/placeholder? I am asking these questions since I couldn't really get the desired behavior!

Unknown said...

I was suggesting IFolderLayout and then just having a tab in there.

Here is a trick. Have an empty view that does nothing as part of your folder, keep it hidden until its time to hide your real view. Have one of these for each folder.

Then do this:
ShowView(trickView)
HideView(myView)
ShowView(myView)
HideView(trickView)

Let me know how that goes.

What we are trying to accomplish here is keep the screen real estate space reserved for the view you are hiding/showing.

This should work but if it does not then we need to come up with a solution besides hide/show views.

confuzzled said...

Hi Glenn! I tried what you suggested but it is not really helping me make a considerable difference. Actually, there is one particular thing that causes maximum pain in terms of UI. In one of the views that I have contributed, I contribute items to the toolbar depending on which resource is currently open. So what happens here is that whenever say A is opened, XYZ items appear in toolbar and say when B is opened LMN items appear in toolbar. As such it is dynamic and so the toolbar keeps changing. Now the issue is that whenever a new resource is opened and I do the standard hideView/showView - this particular view (lets call it EditorView) actually goes for a second and the view right below it occupies the space which was occupied by EditorView. After this flip second, the EditorView again comes up. But this refresh causing a view to go away and the other view's position to change is quite a pain from the UI perspective. Do you suggest something to resolve this problem?

Unknown said...

So having 2 views in a folder and always having one viewable didnt work?

Again, with the trickView you could keep the toolbar consistent and not flashing different buttons ABC or LMN if the logic also exists in the trickView class to mask the functionality (at least for the toolbar viewing part) as the view you are hiding and showing.

I am quite surprised this does not work.

Can you explain to me what is happening or better yet record a video so I can see the problem and put it on youtube or the like.

Perhaps I am misunderstanding the problem.

You can use a 30 day evaluation of camtasia (the makers of snagit).

Please do this and I bet we can figure this out.

confuzzled said...

First of all thanks so much for spending so much time and effort to try and resolve this issue for me... apparently I was doing the sequence wrong.

I was doing:
showView(trickView);
hideView(myView);
hideView(trickView);
showView(myView);

The gap between the last two calls caused the other view to expand into the other view's space. Thanks a lot, this does remove the misplaced views appearance and it looks much better! :)

There is still quite a bit of flickering but I guess that's due to showView/hideView (and there is no immediate resolution to this other than probably referring to Albireo code and how they have solved these problems).

But thanks again for all the help! :) It's been great interacting with you..

I am going to keep a close watch on your blog! :)

Unknown said...

Glad it helped some. If you find a better solution please do share it!

adam said...

What PDF control are you using? is there any PDF renderer pure SWT? thank you.

Unknown said...

There are none, I am using IcePDF which was just released as opensource, check it out here:
http://www.icesoft.com//press-releases/icepdf-open-source-java-pdf-05-01-09.html