Joined: Aug 29, 2004 Posts: 4 Location: Ahrensburg
Posted: Sat Sep 23, 2006 5:30 am Post subject: Focus and selection irritations in NO 2 Beta 3 Patch 1
Hi out there!
Mostly I am testing Neo fully automated but sometimes my wife needs some documents I haven't used the Aqua version before but some differences to the X11 version are visible with a first look. Focus and performance issues are mainly in my personal focus because OOo X11 is slow but the new Aqua version seems to have now more issues in that area.
Here are some testcases to see what users will see if they try to create a well formatted (via styles, not hard coded formatting!), simple writer document....
Test purpose
Focus and performance behaviour of openoffice.org based builds. Here NeoOffice 2 Beta 3 Patch #1 plus 49 language packs.
Test cases
Test case 1: Stylist
- New Writer document
- Write two sentences and finish both of them with a RETURN-key
- Select the first sentence
- Open the stylist (first button on table toolbar; "Styles and formatting")
Bug #1: You do not see which style has been adopted to the first sentence.
Test case 2
- Run test case 1
- select in the opened "Styles and formatting" window "Heading 1"
Bug #2: The selection will be visible but it looks like a fade-in and makes working slow with this feature.
Test case 3
- Run test case 2
- Right mous click on "Heading 1"-style
- Select in the context menu "Modify"
Bug #3: It needs >4 sec. on a 1.8 GHz PPC (iMac 17") with 1GB memory and Mac OS X 10.4.7 with Java 1.5.0_06 selected in NO
Test case 4
- Create a Writer document with a table in it
- Save the document while the cursor is in a table cell
- Close the window/document
- Load the document again
Bug #4: It takes >10 sec. until the toolbars will be painted by NO.
BTW: AFAICS neither Pages nor OOo X11 (1.1.x and 2.x) have these issues.
Greetings
Jogi _________________ Joerg (Jogi) Sievers
ISTQB(R) Certified Tester, Foundation Level
Posted: Sat Sep 23, 2006 7:35 am Post subject: Re: Focus and selection irritations in NO 2 Beta 3 Patch 1
jogi wrote:
Test case 1: Stylist
- New Writer document
- Write two sentences and finish both of them with a RETURN-key
- Select the first sentence
- Open the stylist (first button on table toolbar; "Styles and formatting")
Bug #1: You do not see which style has been adopted to the first sentence.
I cannot reproduce this. On my machines, the adopted style is always highlighted by my system highlight color (light blue in my case). Maybe this was fixed by my latest test patch in bug 1685?
jogi wrote:
Test case 2
- Run test case 1
- select in the opened "Styles and formatting" window "Heading 1"
Bug #2: The selection will be visible but it looks like a fade-in and makes working slow with this feature.
What you are seeing here is the difference in speed between text layout on X11 and native ATSUI text layout.
Some background: X11 text layout operations are very cheap but they don't render pretty, anti-aliased, well-kerned results. ATSUI, in constrast, produces these pretty results but its text layout operations are an order of magnitude more expensive than X11 text layout operations.
In NeoOffice, I try to mitigate the extra overhead of ATSUI by caching the last 256 text layouts. However, in this particular test case, the OOo code is requesting a very large number of text layouts. Specifically, here are the numbers:
Text layouts requested: 107
Text layouts not in cache: 2
Potentially I could improve my cache lookup performance (there is a lot of preparation that must be down to get the text string broken down into runs that ATSUI won't mess up) but the OOo code isn't helping much by the large number of text layouts. This is a lot of layouts for now actual changes in onscreen (or offscreen) text. In theory, there should only be a handful of text layouts done in this case.
jogi wrote:
Test case 3
- Run test case 2
- Right mous click on "Heading 1"-style
- Select in the context menu "Modify"
Bug #3: It needs >4 sec. on a 1.8 GHz PPC (iMac 17") with 1GB memory and Mac OS X 10.4.7 with Java 1.5.0_06 selected in NO
This particular test case is what I use to evaluate the size of our ATSUI text layout cache as I have found that some of the tabs in this dialog do an astounding number of text layouts. For example, if the dialog's "Fonts" tab is selected when the dialog appears, the following number of text layouts will be done:
Text layouts requested: 16264
Text layouts not in cache: 1848
More than 16000 text layouts are requested by the OOo code and of those nearly 2000 are for new strings! That is a lot of strings and, frankly, there aren't more than a few dozen strings visible in that tab at any one time.
jogi wrote:
Test case 4
- Create a Writer document with a table in it
- Save the document while the cursor is in a table cell
- Close the window/document
- Load the document again
Bug #4: It takes >10 sec. until the toolbars will be painted by NO.
This lag is actually a hack to make the preparation on the native menus less noticeable. In order to properly setup native menus, we need to make a pass through each menu item and send each an activate and deactivate VCL event. VCL menus are optimized by not creating their menu items or submenus until they receive an activate event as creation for some menu items is an expensive process for OOo.
The problem we had was that any changes to Java native menus did not take effect after the native "begin menu tracking" event is received. In this native event, the menu or menu item that you are selecting is not yet known. I believe Pavel ran into this same problem while working on the OOo Aqua demo. Because of this, we must allow any pending VCL events to be dispatched (so that the VCL event state is in sync with the native event state) and then send each menu item another activate and deactivate VCL event.
This may seem like duplication or work (and it is). However, the second pass through the menu items in the native "begin menu tracking" event is very quick. Originally, we delayed the initial pass until the user first clicked on the menubar, but many users complained about the app "hanging" for 10 seconds so we moved the first pass to just before the window opens.
Joined: Apr 25, 2006 Posts: 2315 Location: Montpellier, France
Posted: Sat Sep 23, 2006 10:35 am Post subject:
jogi wrote:
Test case 1: Stylist
- New Writer document
- Write two sentences and finish both of them with a RETURN-key
- Select the first sentence
- Open the stylist (first button on table toolbar; "Styles and formatting")
Bug #1: You do not see which style has been adopted to the first sentence.
pluby wrote:
cannot reproduce this. On my machines, the adopted style is always highlighted by my system highlight color (light blue in my case). Maybe this was fixed by my latest test patch in bug 1685?
I cannot reproduce this bug with a clean install of NeoOffice 2.0 Aqua Beta 3 + Patch 1 (official builds - no test patches), the French language pack, and clean preferences. I'm also on 10.4.7 for PowerPC. The adopted style is highlighted in light blue.
jogi wrote:
Mostly I am testing Neo fully automated
What do you mean by "automated" (not familiar with automated QA, sorry) ? Did you use an automated process to test Test case #1 ? How can I replicate your steps in an automated way ?
Joined: Aug 29, 2004 Posts: 4 Location: Ahrensburg
Posted: Sat Sep 23, 2006 10:36 am Post subject: Re: Focus and selection irrititations in NO 2 Beta 3 Patch 1
Hi Patrick,
First of all: You have realized a great idea of many "Macies" and that you run into trouble (doubled work, issues of main code tree of OOo etc.) is for none of the projects good. Your beta seems to be a big step forward in the development of your way to make OOo technology available on Mac OS X. So, as I told Edward on OOoCon: I will have a closer look at both Mac OS projects if my free time gives me the choice.
pluby wrote:
I cannot reproduce this. On my machines, the adopted style is always highlighted by my system highlight color (light blue in my case).
Great that you have fixed it. Hopefully I will see it in patch #2
pluby wrote:
What you are seeing here is the difference in speed between text layout on X11 and native ATSUI text layout.
"Apple Type Services for Unicode Imaging" = ATSUI (for those who are not familar with that acronym)
I am a tester not a developer and it makes no difference from my point of view which technology is being used, sorry but I told that also the VCL guys if I have found an issue on X11 Other applications on the same SUT (system under test) do not have this problem - incl. Java applications (okay, with not such a nice font handling, my respect!).
pluby wrote:
ATSUI, in constrast, produces these pretty results but its text layout operations are an order of magnitude more expensive than X11 text layout operations.
It is one of the main goals of user experience to find the balance on that IMHO you know the way but you haven't reached that goal you need to make Macies lucky in that case.
pluby wrote:
In NeoOffice, I try to mitigate the extra overhead of ATSUI by caching the last 256 text layouts. However, in this particular test case, the OOo code is requesting a very large number of text layouts.
It is a normal office operation and it would hinder at lot of customers if you won't have a performance enhancement solution - I am sure...
pluby wrote:
More than 16000 text layouts are requested by the OOo code and of those nearly 2000 are for new strings! That is a lot of strings and, frankly, there aren't more than a few dozen strings visible in that tab at any one time.
Is there a chance (on OOo side) to reduce such huge operations? ALso OOo (X11 or not) need performance improvements
pluby wrote:
This lag is actually a hack to make the preparation on the native menus less noticeable.
It's my job to find "hacks", he, he. That's the reason why I like requirements, code designs, prototypes and specifications... You can see that I do not need to go into the deepness of OOo functionality to find some things the user won't accept in evaluation to make the decision you want he should do...
pluby wrote:
VCL menus are optimized by not creating their menu items or submenus until they receive an activate event as creation for some menu items is an expensive process for OOo.
Ever told that - with a solution or suggestion - to the VCL team?
pluby wrote:
However, the second pass through the menu items in the native "begin menu tracking" event is very quick.
I can not say that. AFAICS it is nearly the same speed... but I haven't done exact counts.
Joined: Aug 29, 2004 Posts: 4 Location: Ahrensburg
Posted: Sat Sep 23, 2006 10:43 am Post subject: Automated GUI Testing
Hi!
Samwise wrote:
What do you mean by "automated" (not familiar with automated QA, sorry) ? Did you use an automated process to test Test case #1 ? How can I replicate your steps in an automated way ?
Automated GUI Testing is my job and I do some testing on Mac OS X OOo builds (incl. NeoOffice) in my private time - if there is some
The test cases were manually written not from an automated test script.
Joined: Aug 29, 2004 Posts: 4 Location: Ahrensburg
Posted: Sat Sep 23, 2006 10:47 am Post subject:
Hi!
Samwise wrote:
I cannot reproduce this bug with a clean install of NeoOffice 2.0 Aqua Beta 3 + Patch 1 (official builds - no test patches), the French language pack, and clean preferences. I'm also on 10.4.7 for PowerPC. The adopted style is highlighted in light blue.
May be I wasn't clear enough in the test case description:
Also if the cursor is in the document? If the cursor (=focus; when the three Aqua buttons are red, yellow and green) is in the "formatting and styles" dialog also the style is highlighted.
The goal is that always the style is highlighted that you can verify that the adopted style is correct and could be changed with one click.
Cu,
Jogi _________________ Joerg (Jogi) Sievers
ISTQB(R) Certified Tester, Foundation Level
May be I wasn't clear enough in the test case description:
Also if the cursor is in the document? If the cursor (=focus; when the three Aqua buttons are red, yellow and green) is in the "formatting and styles" dialog also the style is highlighted.
The goal is that always the style is highlighted that you can verify that the adopted style is correct and could be changed with one click.
I'm still confused. What I did was the following steps:
1. Create a new Writer document (making sure that the Styles and Formatting window is not visible)
2. Select "Heading 1" in the combobox in the document toolbar
3. Type some text and press the enter key
4. Type some more text and press the enter key
5. Press Control-F11 to display the Styles and Formatting window
After performing these steps, Text Body is highlighted in the Styles and Formatting window and the Writer document window still has focus.
Posted: Sat Sep 23, 2006 12:00 pm Post subject: Re: Focus and selection irrititations in NO 2 Beta 3 Patch 1
jogi wrote:
pluby wrote:
VCL menus are optimized by not creating their menu items or submenus until they receive an activate event as creation for some menu items is an expensive process for OOo.
Ever told that - with a solution or suggestion - to the VCL team?
I don't think that there is necessarily a bug in OOo here. AFAICT, the reason that the activate event is expensive is that for most menu items the application layer code, not VCL, needs to evaluate state of the current document (e.g. cursor position, highlighted text, etc.) in order to determine the enabled/disabled state of a menu item or submenu.
I believe that the delayed updating of menus by OOo is a reasonable approach. The real bug is that with Java native menus, any requests to update a menu item or submenu made after the native "begin menu tracking" event has been dispatched seems to never be delivered by Java to the underlying native Cocoa menus until after menu tracking has ended.
In other words, this is a Java or Cocoa bug, not an OOo bug and our hack is merely a workaround for that.
jogi wrote:
pluby wrote:
However, the second pass through the menu items in the native "begin menu tracking" event is very quick.
I can not say that. AFAICS it is nearly the same speed... but I haven't done exact counts.
Really? After you open a new document window, any clicks on the native menu bar should result in a menu showing almost immediately. That is what I mean by "second pass". The first pass is the lag time before the document window initially appears on screen.
Joined: Apr 25, 2006 Posts: 2315 Location: Montpellier, France
Posted: Sat Sep 23, 2006 12:21 pm Post subject:
pluby wrote:
I'm still confused. What I did was the following steps:
1. Create a new Writer document (making sure that the Styles and Formatting window is not visible)
2. Select "Heading 1" in the combobox in the document toolbar
3. Type some text and press the enter key
4. Type some more text and press the enter key
5. Press Control-F11 to display the Styles and Formatting window
After performing these steps, Text Body is highlighted in the Styles and Formatting window and the Writer document window still has focus.
That's right, except after pressing Ctrl+F11 the focus is not on the document window, but on the stylist window. If you focus on the document window, the light blue highlight will turn into very light gray ...
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
I haven't used the Aqua version before but some differences to the X11 version are visible with a first look. Focus and performance issues are mainly in my personal focus because OOo X11 is slow but the new Aqua version seems to have now more issues in that area.
