<div class="gmail_quote">On Tue, Sep 15, 2009 at 12:11 PM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de">mail@milianw.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Kishore, 15.09.2009:<br>
<div><div></div><div class="h5">> On Tuesday 15 Sep 2009 3:34:25 pm Milian Wolff wrote:<br>
> > Kishore wrote:<br>
> > > On Monday 14 Sep 2009 7:56:30 pm Kishore wrote:<br>
> > >> On Monday 14 Sep 2009 7:14:16 pm Andreas Pakulat wrote:<br>
> > >>> On 14.09.09 16:26:36, Nikos Chantziaras wrote:<br>
> > >>>> On 09/14/2009 03:41 PM, Andreas Pakulat wrote:<br>
> > >>>>> On 14.09.09 15:26:52, Nikos Chantziaras wrote:<br>
> > >>>>>> On 09/14/2009 02:20 PM, Milian Wolff wrote:<br>
> > >>>>>>> Nikos Chantziaras, 14.09.2009:<br>
> > >>>>><br>
> > >>>>> And with "native" KDevelop is simply<br>
> > >>>>> unusable.<br>
> > >>>><br>
> > >>>> What exactly do you mean?  It seems to work great for me.<br>
> > >>><br>
> > >>> It means that with the extensive highlighting we do for C++ scrolling<br>
> > >>> and editing in katepart are horribly slow. We've found that factors<br>
> > >>> influencing this include compositing-effects as well as general PC<br>
> > >>> power.<br>
> > >>><br>
> > >>> Or try a very long line thats dynamically wrapped inside the editor,<br>
> > >>> thats also very slow to edit with native engine, but really fast with<br>
> > >>> raster.<br>
> > >>><br>
> > >>>>>> With all things considered, I don't think KDevelop should use<br>
> > >>>>>> raster on it's own; IMHO that's a choice the user should make;<br>
> > >>>>>> apps should follow the default unless the user says otherwise.<br>
> > >>>>><br>
> > >>>>> Except if the default makes the app in question unusable. We want<br>
> > >>>>> to provide a nice experience from the start, without the User<br>
> > >>>>> having to dig up some obscure cmdline option.<br>
> > >>>><br>
> > >>>> This way we end up with each app circumventing defaults.  Imagine if<br>
> > >>>> each app would do that.  Users would have to configure each and<br>
> > >>>> every one separately and we're back to the 1980's.  Surely I'm not<br>
> > >>>> the only one who sees something wrong about this approach?  On most<br>
> > >>>> systems, Qt is not configured with raster as default, and there's a<br>
> > >>>> reason for that.<br>
> > >>><br>
> > >>> How do you measure "most systems"? I've got 3 at hand and all of them<br>
> > >>> use raster by default. There are in fact only few desktop apps that<br>
> > >>> cannot use raster at all because they rely on certain implementation<br>
> > >>> details of native and the KDE apps among them apply the same code we<br>
> > >>> do to force their app to use native instead of raster - ignoring my<br>
> > >>> configured Qt default ;)<br>
> > >>><br>
> > >>>> In any event, I don't feel too strongly about it, since now I know<br>
> > >>>> how to fix it.  Just mentioning that this might bite lots of people<br>
> > >>>> and it might be a good idea to make this configurable in KDevelop<br>
> > >>>> and using Qt's default by default.<br>
> > >>><br>
> > >>> It already is configurable by using the cmdline switch supplied by<br>
> > >>> Qt.<br>
> > >><br>
> > >> Thanks for this discussion. On my Samsung NC10 (Netbook with intel<br>
> > >>  graphics) KDevelop started to feel really slow the last couple of<br>
> > >> weeks. After this discussion, i wanted to give it a try and launched<br>
> > >> kdevelop with - graphicssystem native. It is so much faster!<br>
> > >> Relaunching without that option make is slow again!<br>
> > >><br>
> > >> May be reconsider that decision?<br>
> > ><br>
> > > For more information, this netbook is running Kubuntu Karmic with intel<br>
> > > graphics driver version 2.8.1 using xserver-xorg version 1.6.3<br>
> > > Qt: 4.5.2<br>
> > > KDE: 4.3.1 (KDE 4.3.1)<br>
> > > KDevelop: 3.9.95 (using KDevPlatform 0.9.95) (compiled from sources)<br>
> ><br>
> > What kind of intel is that? I have one myself at home and will give you<br>
> > my setup later on. Though I have still Jaunty, but a lot of backported<br>
> > intel drivers.<br>
> ><br>
> > I'll get back to you later today.<br>
><br>
> GMA 950.<br>
><br>
<br>
</div></div>$ lspci | grep VGA<br>
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960<br>
Integrated Graphics Controller (rev 0c)<br>
<br>
libdrm-intel1:<br>
Version: 2.4.13~git-0ubuntu0tormod~jaunty<br>
xserver-xorg-video-intel:<br>
Version: 2:2.8.99.901~git20090914.c2abfa8e-0ubuntu0tormod~jaunty<br>
kernel:<br>
2.6.30-020630-generic<br>
Qt version 4.5.2<br>
<br>
And I have no problem with -graphicssystem raster<br>
<br>
Maybe a regression in karmic?<br>
<br>
--<br>
<div class="im">Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
</div><a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
<br>_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br></blockquote><div> </div></div>I've been using intel and I haven't had any problem with intel with any driver+kernel combination using raster, so it's definitely something else.<br>
<br>I'm working with  2.6.31 and intel 2.8 works like a charm now :D<br>