Before you move the ChimericalConsole system hack and reboot, can you try the following test patch?
It may not help, but in the following test patch I no longer create an temporary CGLayer objects from an existing CGLayer's graphics context. In other words, I removed chaining of these Mac OS X drawing objects and now all temporary CGLayer objects are created from their own unique bitmap.
If you see no change with the above test patch, can you move the ChimericalConsole system hack folder, reboot, and see if you still see either the drawing errors or the crashing? If there are still problems after that, then check for any "soffice.bin" Console messages.
After a quick test, Patch-4-Test-5-Intel seems to have fixed the problem, without having to remove ChimericalConsole or do anything else.
I won't have much time in the next few days to keep testing, but in the amount of scrolling and selecting I've done already, I would formerly have seen the artifacts.
(FWIW, ChimericalConsole checks to see if it's being loaded into Camino, and if not, does nothing in every other app. Unless the act of being loaded and checking to see the "host" app can affect drawing code, it seems unlikely that it would have been the trigger. Stranger things have happened, of course, but so far it seems not to have been )
Thanks for the patch!
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
After a quick test, Patch-4-Test-5-Intel seems to have fixed the problem, without having to remove ChimericalConsole or do anything else.
That is good to hear that the test patch worked. Fortunately, the fix was a simple one and it should not affect performance. I think the bug shows that using Mac OS X's CGLayer functions do have some fussiness that is tied to your machine's graphics card so the test patch's approach of creating a CGLayer from a small bitmap seems to be the safest approach.
I am noticing that the icons in the toolbar at the top of my window have a horizontal line at the top when they are active or highlighted by mouseover. It isn't there when the icon is just in the toolbar.
Is this caused by the new drawing code? _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
I am noticing that the icons in the toolbar at the top of my window have a horizontal line at the top when they are active or highlighted by mouseover. It isn't there when the icon is just in the toolbar.
I am not seeing what you describe on my Mac OS X 10.5 machine so can you post a small screen snapshot. Also, what version of Mac OS X are you running?
Edit by pluby: To take a screen snapshot, select the Command-Shift-4 keys on your Mac and drag your mouse to highlight the area on the screen where the error is displayed. After you highlight an area and release your mouse, a new image file will appear on your machine's desktop that you can attach to your post.
I also installed on Mac OS X 10.7.3 the latest test patch that I posted yesterday that fixes the saving EPS images to .doc file bug in NeoOffice's underlying OpenOffice.org code and I do not see any drawing artifacts after mousing over toolbars in Writer.
Is it possible that you are using an older test patch? If so, can you install the latest test patch that I posted in the above post from the following URL and see if the problem is still there? If so, then attach a screen snapshot and your Mac OS X version:
Attached is a screen snapshot of how NeoOffice 3.2.1 (i.e. the full old Java code) looks on my 10.5.8 machine. The navigator and left justification buttons (as well the unselected but mouse over the crayon button) look the same as your screen snapshot to me. Am I missing some detail?
Nope, entirely the same. I just saw it and wondered if it was new or old.
Note: in the latest test patch I put a fix in for some cases where unhighlighting text in Writer would leave a faint line. If you see any cases like that, please post them as we ran into many of such cases when we first implement drawing using Java.
I have finished the next major phase of our NeoOffice "de-Javafication"
work. So now, in addition to fully native printing and offscreen image drawing that was in previous test patches, the latest test patch in the link at the end of this post now runs fully native code without using Java:
Native window drawing
Although we still use Java to create and show Mac OS X windows, we now have fully bypassed Java and draw directly to the native window that Java creates using Apple's Cocoa and Core Graphics functions.
No Java fonts
We have used native fonts for several years to layout text. However, because we used Java, we had to offload drawing text to Java. Now that we can draw directly to the native window that Java creates, we can bypass Java and draw our existing native text layout output directly to the native window.
If anyone can install the test patch. If our new non-Java code is working correctly you should see zero changes in NeoOffice's behavior. So, if anyone sees anything drawn differently in a document or dialog window, please let us know and we will investigate. Also, CPU usage not have changed in the new code so if you see very high CPU usage, definitely let us know:
Patch installed and all is looking good in Writer so far. Redrawing performance feels better, is that just my imagination?
Possibly drawing is faster. With the native drawing we use Mac OS X CGLayer objects to draw to. When you draw to a CGLayer object, nothing gets drawn. Instead, the CGLayer just stores the drawing operations that you drew.
This potentially gives improced performance because when using Writer (and probably in parts of Calc and Impress), all document drawing is actually done in 2 steps:
1. Draw text and shapes to an offscreen image
2. Copy portion of offscreen image to document window
Before with Java (and still in OpenOffice.org and LibreOffice), offscreen images are real bitmaps in memory and drawing in step 1 in cause real drawing to the bitmap. Then step 2 involves copying the individual pixels from the offscreen bitmap and drawing a bitmap to the document window.
With our CGLayer native code, step 1 really just saves drawing operations like "draw text at point x and y" so in step 2, copying the offscreen image CGLayer really just replays the saved drawing operations to the document window. In other words, if we are drawing only shapes and text, the Apple's CGLayers are really good at avoiding doing any real drawing until needed.
Note that the above is my interpretation of what Apple's CGLayer documentation says so how I assume that how the details of how they work is quite complicated but so far it seems to me that CGLayers are a really good replacement for drawing to large bitmaps in memory.
A donor found a bug in the last test patch. The bug caused lines that are less than 1 pixel wide to not be drawn in some cases. The bug was caused by replicating our approach for handling drawing shapes with a width or height of less than 1 pixel width in Java. The approach we used for Java apparently does not work in native drawing so the following test patch uses a new approach to ensure that this thin lines get drawn correctly.
So, if you installed my last test patch, please install the following one to get our latest code:
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
)
.