Bugzilla – Full Text Bug Listing
| Summary: | [Shell] computeTrim inconsistent with menus | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | John Gymer <jgymer> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ivan |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
John, when you start your application for the first time (after server start) all calculations initially are based on the text size estimation (no real text size measurements available). RAP will measure the real text sizes and will do the layout again. In the sequential sessions, the real text sizes will already be known - measured in the first session. That's why it's normal to have small differences between the very first and the next sessions. For me this bug is invalid. Text Size Determination (TSD) is a specific technique in RAP and it's not possible to avoid this difference. Oh dear. How far does RAP have to get before anything involving text size calculations is reliable then? Is it just a case of actually displaying a shell with a title bar, or menu bar or something? So, as a workaround technique, could I create a shell with trimmings as desired, calculate it, destroy it and carry on, or does the shell actually physically have to pop up visibly on the browser before I can be sure of the calculations being accurate? Thanks, John (In reply to comment #2) > Oh dear. > How far does RAP have to get before anything involving text size > calculations is reliable then? > Is it just a case of actually displaying a shell with a title bar, or menu > bar or something? > So, as a workaround technique, could I create a shell with trimmings as > desired, calculate it, destroy it and carry on, or does the shell actually > physically have to pop up visibly on the browser before I can be sure of the > calculations being accurate? > Thanks, John Let me explain to you how Text Size Determination works in RAP: 1. Some text size is requested by the code (computeSize, computeTrim, etc). 2. A "database" is queried for existence of a real measured size. 3. If measurement is missing, the text is sent to the client for measurement. 4. A new request is sent form the client immediately with the new (real) size. 5. The real size is kept into the "database" and re-layout is triggered to respect the new text sizes. Ofcourse, if the text size is already measured, it's used directly. Normally, the difference between estimated text size and the real measured size is small, but it depends on the language (Chinese for examples), text length or wrap width. Ok, understood, so I wonder if there is another problem here then... in IE9 I get a HUGE difference in the calaculations from ComputeTrim... the height varies by +38 between 1st call and subsequent. Seems like more than I'd expect. Other browsers give much smaller differences, but do still give some difference e.g. Chrome gives +3, FireFox gives +5, Internal Browser gives +4. Is the huge difference in IE explainable still, or is something else wrong? Thanks, John (In reply to comment #4) > Ok, understood, so I wonder if there is another problem here then... in IE9 > I get a HUGE difference in the calaculations from ComputeTrim... the height > varies by +38 between 1st call and subsequent. Seems like more than I'd > expect. Other browsers give much smaller differences, but do still give some > difference e.g. Chrome gives +3, FireFox gives +5, Internal Browser gives +4. > Is the huge difference in IE explainable still, or is something else wrong? > Thanks, John Usually, the Internal Eclipse Browser on Windows uses installed IE engine. It's really strange that there is such a big different between Internal Eclipse Browser and IE9. Hi Ivan, Are you able to take a look using the snippet I provided, just to validate if the difference in calculations is due to what you think it is? I am concerned that there is another issue hidden by this somehow... Thanks, John (In reply to comment #6) > Hi Ivan, > Are you able to take a look using the snippet I provided, just to validate if > the difference in calculations is due to what you think it is? > I am concerned that there is another issue hidden by this somehow... > Thanks, John Yes... I checked your snippet... Here are my results: First session (after server restart). The result are the same as they are estimated - no real measurement in the browser: - IE9 -> 0,-22,300,322 - Firefox -> 0,-22,300,322 - Chrome -> 0,-22,300,322 - Opera -> 0,-22,300,322 Next session (after browser reload): - IE9 -> 0,-22,300,326 - Firefox -> 0,-22,300,325 - Chrome -> 0,-22,300,325 - Opera -> 0,-22,300,325 Note that the zooming of all browsers is set to 100% - no zoom. I've made a small typo. Next session (after browser reload): - IE9 -> 0,-26,300,326 - Firefox -> 0,-25,300,325 - Chrome -> 0,-25,300,325 - Opera -> 0,-25,300,325 I don't see any hidden issue. For me the bug is invalid. Please reopen if you disagree. Ok for now... although I'm not convinced... +38 on my IE is a huge difference, and it would be good to understand it. Do you have any suggestions in order to force a calculation to get it consistent though? e.g. open a shell with a menu, do the calc, close the shell (dummy shell) etc...? would that idea work? The same issue exists if I open 1st shell (calc is consistent for all browsers), then open a 2nd shell in the same application (don't need new browser session). Therefore I would assume that I could open a 'welcome' screen (for example), get the calc from that, and then I'd be consistent for all shells from that point onwards... does that make sense? I haven't coded this yet, as I don't really want to have to have an opening shell if possible... |
Using shell.computeTrim() to get the size of a Shell with a menu bar gives inconsistent results for each session in RAP. Using the same RAP server instance, the first call to shell.computeTrim() for a Shell with a menu bar gives one result, but open another browse, or refresh same browser and the same logic gives a different result on subsequent calls. RAP seems to remember something internally for the 2nd call, so the information is not reliable. 1st call appears to be the accurate one. Snipped: package bug.snippet; import org.eclipse.swt.SWT; import org.eclipse.swt.graphics.Color; import org.eclipse.swt.graphics.RGB; import org.eclipse.swt.graphics.Rectangle; import org.eclipse.swt.layout.FormAttachment; import org.eclipse.swt.layout.FormData; import org.eclipse.swt.layout.FormLayout; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Label; import org.eclipse.swt.widgets.Menu; import org.eclipse.swt.widgets.Shell; public class Bugsy { private Display display; private Shell shell; private Label label; private Label label2; private Menu menu; public void begin() { System.out.println("BugSnippy Starting..."); // create the Shell display = new Display(); shell = new Shell(display, SWT.NONE); shell.setText("Shell"); shell.setBounds(20, 20, 300, 300); shell.setBackground(new Color(null, new RGB(255,128,128))); FormLayout layout = new FormLayout(); shell.setLayout(layout); Rectangle rect = shell.computeTrim(0, 0, 300, 300); menu = new Menu(shell, SWT.BAR); shell.setMenuBar(menu); Rectangle rect2 = shell.computeTrim(0, 0, 300, 300); //remove the menu again - just used for size calculations of how big a menu would have been shell.setMenuBar(null); //create the labels label = new Label(shell, SWT.BORDER); label.setText("Shell size is " + rect.x + "/" + rect.y + "/" + rect.width + "/" + rect.height); //create the labels label2 = new Label(shell, SWT.BORDER); label2.setText("Shell size is " + rect2.x + "/" + rect2.y + "/" + rect2.width + "/" + rect2.height); //set label's position FormData fd = new FormData(); fd.left = new FormAttachment(0, 5); fd.top = new FormAttachment(0, 5); fd.width = 250; fd.height = 20; label.setLayoutData(fd); fd = new FormData(); fd.left = new FormAttachment(0, 5); fd.top = new FormAttachment(0, 40); fd.width = 250; fd.height = 20; label2.setLayoutData(fd); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); System.out.println("BugSnippy Done!"); } } Purpose of the code is to calculate the size of a menu bar, if there were one. To test, use the snippet with a simple entry point to start the begin method. Run the RAP app, see the results (0,-22,300,322 expected), then add the menu bar and recalculate size gives different results on first call compared to all subsequent calls until RAP server is restarted. Different browsers give different values, but principle is consistent. IE gives most noticeable discrepency if you want to most visibly see the problem, but it occurs on all browsers and all devices that I tried. Thanks, John