1.66 KB, text/plain
1.59 KB, text/plain
1.51 KB, text/plain
2.83 KB, patch
|Details | Diff | Splinter Review|
2.84 KB, patch
|Details | Diff | Splinter Review|
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020123 (#1) Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.7) Gecko/20011226 (#2) Fonts with size>6 are displayed the same as size=6 when displayed remotely. They display properly on my local display. The maximum size is smaller with lower DPI fonts. In both cases (100DPI and 75DPI), the maximum size is at the point where the font would be antialiased, so my fonts are never antialiased when running remotely. also, the same thing happens if I log in to the console on the remote machine: machine #1 => #1: properly sized fonts #1 => #2: big fonts too small #2 => #1: big fonts too small #2 => #2: properly sized fonts so this doesn't seem to be anything specific to either installation of Mozilla or X. Attachments from given URL with NS_FONT_DEBUG=C to follow.
Created attachment 66625 [details] NS_DEBUG_FONT=C, displayed remotely largest font (size=6) is no longer scaled up to proper size
Created attachment 66626 [details] NS_DEBUG_FONT, displayed remotely with 75DPI fonts all 3 sizes (5, 6 and 7) are displayed the same size, not scaled.
After examining my own attachments more closely, it appears that the fonts are simply not scaled. The correct sized font is chosen, but not scaled. Changing description.
Andrew, your analysis is complete correct. Anti-alias scaled bitmap (AASB) fonts work by using XGetImage to bring the background down from the X server, blend the glyphs onto the background, and then sending the background (now with glyphs) back to the X server using XPutImage. Bringing down the background and then sending it back up require a large amount of data to be transfered between the X client and the X server. Moving a large amount of data between the X client and the X server when the client and server are on the same machine takes a modest amount of time as the bandwidth is high. Moving a large amount of data between the X client and the X server when the client and server are on different machines can take a huge amount of time as some network links have limited bandwidth. Because this, code was specifically added to test to see if the X server is local and if so not allow AASB. See bug 112522.
old email: --------------------------------------------------------------------------- Brian Stell wrote: > Andrew Schultz wrote: > > I discovered that I am unable to reproduce this bug when I run Mozilla > remotely (run on another machine and display on my workstation) because > Mozilla does not antialias the font. Do you know why this would be, and > do you know a way to force it to anti-alias? Set this pref in unix.js to true to force AASB to be used for all fonts. pref("font.scale.aa_bitmap.always", false); ------------------------------------------------------------------------ "font.scale.aa_bitmap.always" does not override the "only scale locally" (nor should it, IMO) this seems to be part of bug #112506 reopening and changing to RFE. I have a working patch that adds a pref to override "only scale locally". If an uber-pref (like bug #112506) is preferred, one of the current prefs (font.scale.aa_bitmap.enable ?) will get replaced. Let me know.
A pref for allowing remote AASB is a good idea. Maybe something like pref("font.scale.aa_bitmap.remotely", false); > "font.scale.aa_bitmap.always" does not override the "only scale locally" I agree with this. Are you interested in working on this? I would be glad to guide you.
Created attachment 66710 [details] [diff] [review] patch to add font.scale.aa_bitmap.remotely I attempted to model the pref setup after what is in nsFontMetricsGTK.cpp.
The other AASB controls are here: http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#904 Could we put them all in one place? (Either place is okay with me. I'v been lazy and just added them to the Gtk code but you are correct in placing it in the x11shared code.)
Created attachment 66712 [details] [diff] [review] a better patch don't printf info, free xpref in FreeGlobals, and xAABitmapScaleRemote(+ly)
I was trying to figure out how to get it in there, but the check needs to be done in nsXFontAAScaledBitmap::InitGlobal, and based on my limited knowledge of c++, nsFontMetric's global variables (like gAABitmapScaleRemotely) would not be seen by nsXFontAAScaledBitmap's functions. Or nsFontMetric::InitGlobals would need to pass it as a variable when it makes the call.
I suspect you can just declare them global in nsXFontAAScaledBitmap.cpp and external in nsXFontAAScaledBitmap.h
Can we avoid introducing new global variables, please ? Global variables have to be removed when we want to make the code in gfx/src/x11shared a shared library to "share" the code between the gfx modules (gfx, xlib, xprint), otherwise the various modules will overwrite the vars used by other modules, causing havoc and death(=core dumps).
The other (#3) alternative would be check for remoteness of XServer within nsFontMetrics.cpp Putting the pref in nsFontMetrics.cpp and doing #2 (passing a parameter) or #3 also allows the pref to be font-specifc (ja, ko, etc...)
I don't think making it extern will work. the pref can't be static and extern at the same time. I don't think it *needs* to be static, but making it not static is a bit hackish (since all the other prefs are static).
Roland: now that we have some code in the x11shared dir do you have any thoughts on how to handle shared data?
The patch looks fine to me. Roland is maintainng the moz 'Xlib' graphics code and I have been trying to keep him informed of changes the the moz 'GTK' graphics code so he could keep his version in sync. As we have waited a while and not heard anything from Roland I think we should go ahead and get this in. firstname.lastname@example.org Roland, kindly let us know if you thoughts on follow up work. Please feel free to reopen this bug as necessary. if you
this is an RFE so move target to 1.1
What is the status of this? Has the patch landed?
Comment on attachment 66712 [details] [diff] [review] a better patch Requesting superreview on a 9-year-old patch to code that is no longer in the tree, from a person who has never been a superreviewer and also hasn't been involved in the project for the better part of a decade doesn't seem like it's going to lead to much happening.
He seemed relevant at the time the patch was developed. Thanks, that is the information we needed to find out. I just wanted to check if the bug is still relevant. It seems smontagu knows the answer, thanks.