ISSUE :cairo-with-xlib-xrender option ,rendering is not proper.
Title: Samsung Enterprise Portal mySingle 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 reply Thanks in advance Muthukumar S.Muthukumar | Lead Engineer -DM RD | Samsung India Software Center,Noida | Office Phone - 91- 120-4081234-36, Ext : 1636 | Mobile : 9953556847 www.samsungindia.com/sisc/ Attach1.1.txt Description: Binary data Attach2.2.txt Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: This means abstracting everything with pointer indirections leading to slow Any performance problems you may have are not caused by excessive pointer dereferences. feature-bare toolkits. Which features are you missing from current toolkits? Instead, X should have been ported to those systems and the widget toolkits should have only been a slight bit of sugar around an enhanced Xlib. If i ever do anything cross-platform, it will only be when an Xlib or an enhanced replacement of it is ported. I very much look forward to your new X toolkit: please let us know when it's available. In the meantime, let's just limit our recommendations to things that exist. pgpkSNKCrDYmD.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Sat, Jan 30, 2010 at 12:10:11PM +1100, Russell Shaw wrote: None of this really matters because i don't care if i'm the only one that uses this stuff. I'd prefer to be ignored as a troll because I have a better job than programming all day and just hack on it as a hobby for my own use. Would have been good to see existing software a bit better though. I'm now productive so i'm happy. I'm glad to hear it, but yeah, this is hugely offtopic for x...@. pgpULTMOS8zbw.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Re-mapping the middlemouse paste functionality
On Fri, Jan 29, 2010 at 06:19:48PM +, Ross Burton wrote: On Fri, 2010-01-29 at 10:58 -0500, Adrian Sud wrote: Any googling and browsing of FAQs finds ways to disable the 2nd mouse button entirely, or map the 2nd mouse button to another button (causing all other functions tied to the 2nd mouse button to move to that other button as well). Am I to assume that this is not a configurable thing? xmodmap should let you reassign the button codes (so the middle button is 7 and some side button is 2), but I suspect that this has changed now that XKB is ruling. Worth a go though. xmodmap is still fully supported, and if it's broken, please file bugs. Cheers, Daniel pgpdLPsGSyrRT.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Slow 2D with radeon KMS
Hi, I just tried KMS with radeon driver, and 2D seems notably slow. Widgets takes time to draw, scrolling in Dolphin or Firefox lags, as if some 2D acceleration was not working alright. Used latest 2.6.33rc5 kernel + drm modules from : http://download.opensuse.org/repositories/home:/jobermayr/openSUSE_11.2/x86_64/ http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/x86_64/ Relevant xorg.log : http://88.191.15.45/RVRV/Xorg.0.log.kms Is this normal due to early state of development, or am I missing something? Thanks in advance for any advice. Dam ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
bad results with ATI x1600 and Samsung 27 P2770HD
i have an ati x1600 and samsung p2770hd and i do have output but results are bad. scrolling lines, maybe refresh rate is low and colors look different like red is missing. i've tried several xorg.conf combinations and xrandr and similar tools but nothing changed. can anybody suggest how to make this work? on ubuntu/karmic: $ dpkg -l|grep video-ati ii xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1X.Org X server -- ATI display driver wrapper $ lspci|grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600] Aljosa Mohorovic ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: This means abstracting everything with pointer indirections leading to slow Any performance problems you may have are not caused by excessive pointer dereferences. Not directly. In the context of widget kits, pointer dereferences often hide from the programmer what low level function is being called, especially when there's multiple levels. More of a pain to understand and write code knowing it will run well (sigh broken record). feature-bare toolkits. Which features are you missing from current toolkits? Foolproof multithreading. I should be able to easily have two windows being updated from different threads without interaction problems due to static vars in the toolkit. Until relatively recently, various toolkits had no kind of centralized hot-button help system that i could find. It's way too hard to make a new non-trivial widget when it should be much easier. Many widgets have performance problems when you want to scroll through 10k items from a database. I'm sure they can be made to work well with enough detailed knowledge of the widget, but to get that far, i had to figure out how widgets and everything should work because of lack of know how and documentation. Makes a toolkit rather pointless when the barrier to being productive is that high. I should be able to fork and exec from within a GUI program without problems. A gui framework baggage that comes with widgets should be minor in memory cost. Last time i was using gtk, there was no definitive way of parsing configuration files (tho there is now i think). I wanted ligatures and proper kerning in fonts. I wanted access to all the features in a truetype font file. Last i looked, pango had little documentation about using it in great or sufficient detail. Not knowing anything about non-english text, i had no hope of even knowing what to ask about pango. A simple block diagram of how it processes utf8 clusters would have gone a *long* way. Some explanation of what's in a font file and what contextual analysis is would have helped a lot. I wanted more control over hints for the window manager. That may have already existed, but there was no overview documentation in gtk about that years ago when i used it. I had to learn all the fine details of Xlib and icccm just to figure out what questions to ask. I wanted printer support. I know now that's rather vague and out of scope for widgets. There were no gtk docs explaining that. I used to be using the printer GDI in windows. There was no support for widget settings persistance, or docs saying what to do about it. If i last used a file dialog on a certain directory, i wanted it to open there next time i used the program. I know what i should do in my own way now. There was no drawing support in gtk other than gdk which i found over a year later was xlib calls. Ran slow as hell. Could use cairo now, but i stick closer to the metal and use opengl or shm images. Cairo can draw to a printer context iirc, but i'd rather just generate postscript output directly. I wanted to have accurate colour management, but i see that as out of scope of widgets now. I wanted to programmatically generate menus on the fly that adapt to the results of database retrieval based on ealier stages of the menu hierarchy. At some point gtk changed to XML files to define menus. That totally pissed me off and was when i abandoned gtk. I wanted to do window-in-window mdi. Any mention leads to howls of denial that you don't need it or it's unuseable because you can't use the app on a dual-head setup. Well, i wanted to just a drag an embedded mdi document with a mouse so that it magically becomes a top-level window. Likewise, i could drag it over the mdi container and it would become re-embedded and managed by the mdi window manager. I wanted to have a widget that acts as a window manager complete with icon handling. Then i could use a family of related applications within that shell widget, and have them all appear there in the same state next time i log on. I wanted to make independent X apps such as editors become embedded in my own widgets. I still think about that area. I wanted the whole thing to run well on a 10MHz 8-bit cpu. It still would if i omit scaleable shaded 3D buttons and do another suitable small windowing system. Memory limits for a full unicode font and various window buffers would be pushing it a bit. I still aim for that efficiency. I've read the qt book and tried qt and read the stroustrop book multiple times and know everything about C++ but remain unimpressed at the complexity of C++ toolkit code compared to the results achieved. I find C++ harder to understand and debug compared to C. Gdb had problems with C++. GObject was unsufficiently documented to achieve a full working knowledge of what it is doing. I might be able to figure that out now, but i still find the rest of gtk too tedious to use in C.
Re: Slow 2D with radeon KMS
I just tried KMS with radeon driver, and 2D seems notably slow. Widgets takes time to draw, scrolling in Dolphin or Firefox lags, as if some 2D acceleration was not working alright. I experience the same, running Ubuntu-10.4-alpha2 on my HD3850. Logs look quite normal as far as I can tell. I experience very low performance, and many visual artifacts even when running without composition manager. Should I open a bug-report about the corruptions and attache logscreenshots or are those problems known and to be expected due to the experimental nature of radeon-kms? - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Slow 2D with radeon KMS
On 01/30/2010 04:35 PM, Damien Mir wrote: Hi, I just tried KMS with radeon driver, and 2D seems notably slow. Widgets takes time to draw, scrolling in Dolphin or Firefox lags, as if some 2D acceleration was not working alright. Used latest 2.6.33rc5 kernel + drm modules from : http://download.opensuse.org/repositories/home:/jobermayr/openSUSE_11.2/x86_64/ http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/x86_64/ Relevant xorg.log : http://88.191.15.45/RVRV/Xorg.0.log.kms Is this normal due to early state of development, or am I missing something? It's normal. Radeon KMS is still experimental even in 2.6.33rc kernels. At least the R600/R700 part of it, not sure about R500 and below. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Slow 2D with radeon KMS
On Sun, Jan 31, 2010 at 12:35 AM, Damien Mir mailings.x...@mirabel-sil.com wrote: Hi, I just tried KMS with radeon driver, and 2D seems notably slow. Widgets takes time to draw, scrolling in Dolphin or Firefox lags, as if some 2D acceleration was not working alright. Used latest 2.6.33rc5 kernel + drm modules from : http://download.opensuse.org/repositories/home:/jobermayr/openSUSE_11.2/x86_64/ http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/x86_64/ Relevant xorg.log : http://88.191.15.45/RVRV/Xorg.0.log.kms You really want to be using a 1.7 X server with KMS radeon or nouveau. Dave. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Building X from scratch, jhbuild method - wiki page
Having too much time on my hands, I'm trying building X from scratch, per: http://xorg.freedesktop.org/wiki/JhBuildInstructions I've added to the instructions for how to do it on Ubuntu 9.10. (jhbuild required about 300MB of faff.) Obviously the world isn't Ubuntu or even Linux, so notes for other distros and OSes would be appropriate. (Last time I compiled X from scratch it was FreeBSD in 2003 and took three days ...) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
modular build, libGL make install fails
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 make[3]: *** [install-headers] Error 1 make[3]: Leaving directory `/home/fun/git/mesa/src/mesa' make[2]: *** [install] Error 1 make[2]: Leaving directory `/home/fun/git/mesa/src/mesa' make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/fun/git/mesa/src' make: *** [install] Error 1 *** Error during phase install of libGL: ## Error running make install *** [66/168] 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 ... What's an appropriate workaround here? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular build, libGL make install fails
On 31 January 2010 02:44, Jeremy Huddleston jerem...@freedesktop.org wrote: 1) mesa has its own list Mm. I thought it was relevant to here since it's a mandatory part of building Xorg at all. 2) you want to use sudo for make install. You need root permissions Ah, but I don't, you see. I'm trying to build this thing (Xorg in all its glory) in my home directory. (Using jhbuild to pull all modules from git and build them module by module.) So why is whatever configuration Xorg is giving Mesa telling Mesa to try to install in the system? That bit's Xorg, not Mesa - Mesa is a third-party inclusion, but it's Xorg giving it build parameters. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
