Opened 9 years ago

Closed 9 years ago

#29 closed task (fixed)

Port AWT

Reported by: dmik Owned by:
Priority: blocker Milestone: Beta
Component: general Version:
Severity: Keywords:
Cc:

Description

AWT is a lower level Java GUI toolkit that very closely maps to the underlying OS primitives. Swing is partly based on AWT.

Change History (20)

comment:1 Changed 9 years ago by dmik

AWT uses DDraw from Odin32 which uses MS COM stuff. The macros for defining COM stuff are defined in Odin both in wine/obj_base.h and in wine/dd_obj_base.h which creates a huge bunch of conflicts. Solving this now. Quite a tricky code (as the whole COM though).

comment:2 Changed 9 years ago by dmik

The Odin problem has been fixed in r 21479 there. Moving further.

comment:3 Changed 9 years ago by dmik

awt.dll builds after r193. Will test it now.

comment:4 Changed 9 years ago by dmik

Tested a bit. It loads, but requires java.awt.image.* for doing anything useful. Working on that.

comment:5 Changed 9 years ago by dmik

It was needing mlib_image.dll actually. Built it now. The next is fontmanager.dll.

comment:6 Changed 9 years ago by dmik

fontmgr.dll builds now. Moving further.

comment:7 Changed 9 years ago by dmik

The FontManager? can't find fonts; working on that.

comment:8 Changed 9 years ago by dmik

After supplying a Lucide Sans font manually, I got the first
hello world AWT app working. It however shows instability in various areas (no proper redraw on resize, hang on exit, etc). I will deal with that now. Also, I have to find why Odin doesn't supply system fonts to Java.

comment:9 Changed 9 years ago by dmik

Regarding the hang. It's really strange:

command odin libhave any PM window open (except FC)?Result
java -version Release No HANG
java -version Release Yes Works
javac -versionRelease No Works
javac -versionRelease Yes HANG
java -version Debug No Works
java -version Debug Yes Works
javac -versionDebug No HANG
javac -versionDebug Yes Works

100% reproducible. UNI mode. Complete bullshit.

comment:10 Changed 9 years ago by dmik

Found the reason for the hang (which is an endless loop in fact). It's the code that walks the DosQuerySysState? structure that I added to properly query already loaded DLLs in LIBPATHSTRICT=T mode (Odin32 would crash before when starting an app in this mode). Looks like the returned structure is sometimes broken...

comment:11 Changed 9 years ago by dmik

Great. Now the hang has completely disappeared. Right after I made a lot of debugging. And doesn't appear any more when I revert all. Crap. I don't know how to debug it then. This API is known to be extremely bogus and I must be hitting yet another bug.

One reason for the hang could be that the bogus QSLREC record (see odincrt/dos.cpp for the description of the bug) happens to be the last one in the list, which is indicated by pNextRec set to NULL. And when we work around this bug we correct pNextRec and set it to non-NULL and therefore hide the end of the list from ourselves. If for some reason another record happens to follow this last one in the buffer (they are stored in the buffer not necessarily in the list order), we will get an endless loop.

But I can't check this assumption because it doesn't happen any more. Will try later.

comment:12 Changed 9 years ago by dmik

Uggh, found the reason of why closing the AWT frame window doesn't deliver the WINDOW_CLOSING event (and as a result, the hello world application doesn't exit). Somehow the new XP-style SetWindowSubclass?() API in Odin32 is bogus and the WM_CLOSE event (which is a trigger for Java's WINDOW_CLOSING) does not get delivered to AWT.

Switching the Java code to the old subclass API (SetWindowLongPtr?(GWL_WNDPROC)) fixes the WM_CLOSE delivery and also many redraw problems -- I can now press buttons and resize (I get debug assertions in certain places but that's a different story). This switch to the new API (or its active usage) seems to be done after Innotek stopped maintaining its Java port so it may explain why the implementation of the new API is bogus in Odin32.

I created http://svn.netlabs.org/odin32/ticket/18 in Odin to track this bug. I will try to fix the assertions first, before fixing this API itself.

comment:13 Changed 9 years ago by dmik

After r 21524 in Odin, the debug assertion has gone and our Snowman hello-world application now resizes and terminates well.

Tried a simple Swing application. It also seems to work but there is some problem with the font. Apparently Java wrongly takes its metrics so that I get very high letters with zero width (i.e. nothing can be actually seen when typing). Will look at it next.

comment:14 Changed 9 years ago by dmik

  • Milestone changed from Beta to Swing Core

I finally found why fonts didn't work. It's done really stupid. The font subsystem separately decides if it is OpenJDK or not (though it's already known from e.g. the JVM) by checking the presence of the LucidaSansRegular?.ttf file in the java.home/lib/fonts... If this file is present it assumes it's not OpenJDK, tries to use a proprietary font rasterizer (not available in our sources of course) and silently sets a dummy font scaler on failure that does nothing.

By a funny coincidence, LucidaSansRegular?.ttf was the first font that I copied to the fonts folder in order to stop Java from failing because of the complete absence of any fonts.

Anyway, the next step is to instruct Java to look into OS/2 font directories (e.g. C:\PSFONTS and others, according to user.ini) for fonts so that there is no need to create/maintain the java.home/lib/fonts folder at all.

comment:15 Changed 9 years ago by dmik

Forgot to mention that I can run may Swing apps ATM (actually all I tried run, including various demo applications, and even such heavy as Java2DDemo.jar). The only thing is that fonts are ugly now. I have to find how they initialize and use FreeType?. I must say that the font subsystem in AWT (and both AWT and Swing in general) is way too much complex (so many different API layers each with own interfaces, classes, delegates, aggregates and so on), which makes it very difficult to navigate through the code. I actually don't understand why such complexity is necessary at all (looks like the devs wanted to show they are OOP gods instead of providing something simple that just works). OTOH, I now better understand why Java is so heavy and why 3rd party people created SWT :)

comment:16 Changed 9 years ago by dmik

Also, when using the debug build, I get the following assertions from time to time:

#  Internal Error (d:/Coding/javaos2/openjdk/hotspot/src/share/vm/runtime/handles.cpp:32), pid=447, tid=29294614
#  Error: assert(SharedSkipVerify || obj->is_oop(),"sanity check")

#  Internal Error (d:/Coding/javaos2/openjdk/hotspot/src/share/vm/runtime/synchronizer.cpp:3440), pid=454, tid=29753367
#  Error: assert(false,"Non-balanced monitor enter/exit!")

I don't fully understand what they really mean (didn't investigate it deeply so far) but this is something for to do in the feature. (Probably not for the beta though).

comment:17 Changed 9 years ago by dmik

In r213 I fixed font searching. Now JDK picks up fonts installed in the Font Palette and doesn't need to distribute any fonts with it. This differs from Innotek JDK where fonts installed in the system were completely ignored.

comment:18 Changed 9 years ago by dmik

The font stuff is basically done. Note that I had to enable anti-aliasing on OS/2 by default because standard Type1 fonts have bad hinting and look really ugly otherwise. Also, FreeType? doesn't seem to extract (or Java doesn't seem to use) bitmapped versions of glyphs for small font sizes.

Note that this all differs from earlier Innotek ports where a proprietary font rasterizer is used which a) uses bitmapped glyphs correctly and b) gives a slightly different anti-aliasing quality.

comment:19 Changed 9 years ago by diver

  • Milestone changed from Swing Core to Beta

comment:20 Changed 9 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

Turned out that the broken input of national (non-Latin-1) characters was a complete Odin fault, and quite a difficult one. Fixed it in r 21529 there. Works now.

This ticket may be considered as done now.

Note: See TracTickets for help on using tickets.