Issue: cairo-with-xlib-xrender option --rendering is not proper,by which tinyx is used as backend
Title: Samsung Enterprise Portal mySingle Title :: cairo-with-xlib-xrender option --rendering is not proper,by which tinyx is used as backend Hi,We are trying to port gtk-x11 on to an ARM platform and check the rendering performance of gtk on tinyx. For that i compiled cairo-x11 with xlib-xrender enabled. But when i run any application that uses cairo the fonts are not rendered properly and some black boxes are overlapping the some characters of the string and some extra lines are coming behind some characters (as shown in the attached screenshot of gtkperf application that uses cairo with xlib-xreneder option enabled). But if i compile cairo by disabling xlib-xreneder the display is good and fonts are displayed properly, but the time taken for rendering is increasing two times. I think as xrender takes advantage of acceleration available in tinyx/x11 it is speeding up the rendering. But i didnt make any changes in either xrender code or cairo code. Can anyone identify the reason for this improper display if we enable xlib-xrender option in cairo. Is it a bug in cairo/xrender implementation or we are missing some thing else in the configuration?? The configuration settings we are using is mentioned below. we are using cairo-1.8.0, gtk+-2.12.3, pango-1.22.1, fontconfig-2.6.0, freetype-2.3.7, pixman-0.12.0 and tinyx server xorg-server-1.5.1 (R7.4 release) and arm-v7 toolchain used for cross compilation.cairo configuration settings: ./configure --enable-xlib --enable-xlib-xrender --disable-pdf --disable-ps --disable-svg --enable-png=yes --with-x --disable-some-floating-pointWaiting for ur valuable replyMuthukumar ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Remote X
Hi, Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? With a unicode text widget, every time a character is entered, the line or paragraph(s) need to be moved and/or reshaped. This can mean sending a few largish bitmaps for every key press. Other toolkits may add new polygon tesselated glyphs to the XRender cache: http://www.keithp.com/~keithp/talks/usenix2001/ http://cgit.freedesktop.org/xorg/proto/renderproto/plain/renderproto.txt With a cursive font, all the cursive glyphs on a line could compress when the line is close to full, but before the need for a linebreak. That would stress out the cache advantage of XRender. Another problem with XRender is that it's computationally expensive for small systems without polygon hardware. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remote X
Date: Wed, 03 Feb 2010 01:18:01 +1100 From: Russell Shaw rjs...@netspace.net.au User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) Sender: xorg-boun...@lists.freedesktop.org Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? I sure hope it is. I typically run X clients on a variety of machines close and far. It's one of the reasons I like (and depend on) X. At the moment I have windows open on six different machines: the local workstation, one on a LAN, four over a VPN to a data center. Three of the latter display at least in part by transferring pixmap data. Network round-trip latency to the data center is about 20-23 ms at the moment. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remote X
On Wed, Feb 03, 2010 at 01:18:01AM +1100, Russell Shaw wrote: Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? With a unicode text widget, every time a character is entered, the line or paragraph(s) need to be moved and/or reshaped. This can mean sending a few largish bitmaps for every key press. Other toolkits may add new polygon tesselated glyphs to the XRender cache: http://www.keithp.com/~keithp/talks/usenix2001/ http://cgit.freedesktop.org/xorg/proto/renderproto/plain/renderproto.txt With a cursive font, all the cursive glyphs on a line could compress when the line is close to full, but before the need for a linebreak. That would stress out the cache advantage of XRender. Another problem with XRender is that it's computationally expensive for small systems without polygon hardware. As always, if you are facing any actual particular problem, bug reports and patches are more than welcome. pgpTYfbdqJoG3.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remote X
On Wed, 2010-02-03 at 01:18 +1100, Russell Shaw wrote: With a cursive font, all the cursive glyphs on a line could compress when the line is close to full, but before the need for a linebreak. I wasn't aware that there were any toolkits that were powerful enough to do this, assuming you had an expensive OpenType font that allowed it to condense when the line was getting tight. Just putting the glyphs closer together doesn't mean cache stressing, obviously. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Slow operation of makedepend
Hi to all,
I tried to compile firefox on my system, but makedepend took
several hours for 'nsIconChannel.cpp'.
This delay is caused by the gdk/gtk header files which include
each other.
I made some changes in 'parse.c' to speed up the operation.
This might be useful for others, so I'm attaching the details.
diff -urN makedepend-1.0.2/parse.c makedepend-1.0.2-new/parse.c
--- makedepend-1.0.2/parse.c2009-10-11 06:02:44.0 +0200
+++ makedepend-1.0.2-new/parse.c2010-02-01 18:05:54.0 +0100
@@ -257,13 +257,26 @@
return(ret);
}
+/**/
+static void CleanFlag(struct inclist *file)
+{
+ if(file-i_flags DEFCHECKED) {
+ struct inclist **ip = file-i_list ;
+ int i ;
+
+ file-i_flags = ~DEFCHECKED ;
+ for(i = 0 ; i file-i_listlen ; i++) {
+ CleanFlag(ip[i]) ;
+ }
+ }
+}
+
struct symtab **
fdefined(char *symbol, struct inclist *file, struct inclist **srcfile)
{
struct inclist **ip;
struct symtab **val;
int i;
- static int recurse_lvl = 0;
if (file-i_flags DEFCHECKED)
return(NULL);
@@ -282,8 +295,6 @@
}
}
else if (val != NULL srcfile != NULL) *srcfile = file;
- recurse_lvl--;
- file-i_flags = ~DEFCHECKED;
return(val);
}
@@ -298,6 +309,7 @@
if (srcfile != NULL) *srcfile = maininclist;
return(val);
}
+ CleanFlag(file) ;
if ((val = fdefined(symbol, file, srcfile)))
return(val);
debug(1,(%s not defined in %s\n, symbol, file-i_file));
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xkb: Switch delay to a group
Here is my use case: I use Ctrl+Ins for switching between
layouts/groups (Russian and English). But many application suggests hot
keys like Ctrl+Ins+Key so I am out of luck in such cases now. It is
because xserver switches immediately after pressing Ctrl and Shift so
the last key Key pressing means just pressing only that single Key.
This issue is actual with other switching popular keybindings such as
Alt+Shift.
It would be nice if group switching/locked is delayed until I release
Ctrl and Shift (if I don't press Key before, of course). So, I've
investigated xkb source code and here is the big picture regarding the
issue, see xkb/xkbAction.c:
XkbHandleActions(DeviceIntPtr dev,DeviceIntPtr kbd,xEvent *xE,int count)
...
if (pressEvent) {
act = XkbGetKeyAction(xkbi,xkbi-state,key);
if (act.type == XkbSA_LockGroup) /* changing locked_group !!! */
_XkbFilterLatchState(xkbi,filter,key,act);
}
...
XkbComputeDerivedState(xkbi); /* calculate effective group !!! */
My suggestion is to update the code in such a way:
XkbHandleActions(DeviceIntPtr dev,DeviceIntPtr kbd,xEvent *xE,int count)
...
act = XkbGetKeyAction(xkbi,xkbi-state,key);
if (pressEvent) {
if (act.type == XkbSA_LockGroup)
state.group_change_needed = True;
} else { // modifier is released
if (act.type == XkbSA_LockGroup state.group_change_needed)
_XkbFilterLatchState(xkbi,filter,key,act);
}
...
if( pressed any non-modifier Key )
state.group_change_needed = False;
...
XkbComputeDerivedState(xkbi); /* calculate effective group !!! */
What do you think about that?
Regards,
Ilya Murav'jov
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xkb: Switch delay to a group
В сообщении от 3 февраля 2010 Ilya Murav'jov написал(a): Here is my use case: I use Ctrl+Ins for switching between layouts/groups (Russian and English). Try using CapsLock instead, you'll like it :) -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Support open standards! Take a look at this nice presentation: http://www.dwheeler.com/essays/open-standards-security.pdf ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remote X
Patrick O'Donnell wrote: Date: Wed, 03 Feb 2010 01:18:01 +1100 From: Russell Shaw rjs...@netspace.net.au User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) Sender: xorg-boun...@lists.freedesktop.org Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? I sure hope it is. I typically run X clients on a variety of machines close and far. It's one of the reasons I like (and depend on) X. At the moment I have windows open on six different machines: the local workstation, one on a LAN, four over a VPN to a data center. Three of the latter display at least in part by transferring pixmap data. Network round-trip latency to the data center is about 20-23 ms at the moment. Ok. I will keep it as a priority. Other widget toolkits can be pretty slow over networks i have found. I've wondered if they even bother thinking about performance over networks. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
SOLVED: modular build, libGL make install fails
On 30 January 2010 23:17, David Gerard dger...@gmail.com wrote: Is this a bug, or just me? This is doing the modular build with jhbuild: /home/fun/.local/bin/install-check -d /usr/local/include/GL install: cannot change permissions of `/usr/local/include/GL': No such file or directory I'm doing a build in my home directory, but it appears to be trying to do things to the system. Surely that's not right ... It's just me. Due to http://bugs.freedesktop.org/show_bug.cgi?id=26337 , building with jhbuild requires one to shell out to run ./autogen.sh because jhbuild tries to go straight to 'make'. Doing just ./autogen.sh uses the default prefix, which is of course /usr/local . If I shell out and then do ./autogen.sh --prefix=$HOME/mesa then it works properly. Phew! - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
