Updates from January, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • Akarsh Simha 5:12 am on January 5, 2011 Permalink
    Tags:   

    Building KDE and OpenHatch’s buildhelper 


    Photo Credit: “Riding With Despair Prohibitedby Gene Han

    I remember the time when I knew how to write code / fix bugs, but had no clue about build systems, version control or anything like that. And of course I didn’t know how to write clean code. I was trying to make a KStars-like program in MS DOS, “stealing” KStars’ data, but I didn’t know how to do something, so I looked up KStars’ code. It was so much neater than my horrible code. Finally, I gave up on my DOS program and I wrote a mail to Jason Harris, the author of KStars, to say I wanted to help. He pointed me to the docs on building KDE4 on techbase.

    I got stuck a couple of times while building some of the dependencies. I sent a couple of emails to Jason Harris, showing the output from the failed build, but of course, Jason couldn’t keep helping me all the time. The lack of a working build, in fact, caused me to give up for a while. It took attending a KDE Project Day at FOSS.IN 2007 to bring me back.

    Today, I saw a mockup of a “buildhelper” tool that the OpenHatch project is working on making. (If you haven’t heard of OpenHatch, here’s a sentence from the about page: “We believe that our community loses tons of prospective members because learning how and where you can fit in is difficult.”)

    Karen of OpenHatch drew the mockup, and wrote about the buildhelper at the OpenHatch blog. The part about IRC caught my attention.

    Each step has the basic name/description of a step, a more detailed explanation (if necessary), a link (if necessary, e.g. to the relevant git repository), an estimate of how long the step should take, a help button that links to either a relevant OpenHatch mission or other background-info tutorial that a project favors (optional), and a “crap, it didn’t work and I don’t understand why” button that takes the user to the project’s IRC channel (the dev channel specifically, if the project has more than one), where they can solicit help from more experienced project volunteers and point to the specific step where things went wrong.

    I think in my context, the IRC link would’ve saved me.

    The good thing about KDE is that there is a lot of build documentation already. But it would be awesome to make it interactive, and made clear, step-by-step.

    OpenHatch is an open source project, so it’ll be ready when it’s ready. But Asheesh said on IRC that they’re expecting to release this feature by end April, and they’re going to have templates which various projects can fill, to make the tool specific to their buildsystem.

    It would be awesome if KDE participated. I can see that it would benefit the several potential contributors who know some C / C++ from high school etc, but have never worked with a large project that requires a build system.

    Advertisements
     
  • Akarsh Simha 4:45 pm on January 2, 2011 Permalink
    Tags: , , OpenGL,   

    KStars with experimental OpenGL support in RC2 

    Well, this was a little hurried and late, but I introduced some largish changes into what’s going to become RC2 just a few minutes back. No new strings, to the best of my knowledge. Let me explain what they are.

    Harry de Valence worked with KStars this summer and his (GSoC) project involved writing code that would render the sky map with OpenGL, while still keeping the native QPainter drawing, to ensure that KStars doesn’t crawl on older hardware without hardware acceleration. Well, Harry’s task was rather tough, because he had to deal with badly structured code, but he was able to give us a working OpenGL sky map with a few regressions at the end of his project. The most important unsolved problem, however, was that there was no way to switch between the two paint engines at run time.

    We decided not to leave the code in Harry’s branch, and merged it into trunk, so that the code would be more accessible, and we might arrive at a solution at least before release. When 4.6 was branched out from trunk, we had a version of KStars that would throw up a black screen with some text at the corners upon launching! This was one of the regressions with OpenGL — you couldn’t use infoboxes (those boxes that tell you what KStars is looking at, what the time of the simulation is etc.) with GL, so you had to manually disable them to see the sky map. And to add to that, we had a couple of other problems with GL. And you couldn’t switch out of GL without rebuilding KStars.

    Of course, one of the solutions was to just disable GL and fallback to QPainter, without adding any new functionality, but lots of new code. I didn’t want to subscribe to this — it gives me this feeling that I’m doing what some proprietary software companies do to enforce DRM.

    Our solution to this problem involved breaking up a class that’s very central to KStars — the SkyMap class, which took care of the sky map in totality — painting, projection, events. Not good. Harry had already broken away projection, and in the process of cleaning the code, solved several really strange bugs in KStars. What was left was to break up painting and event handling, so that we could change our canvas at run time.

    This time of the year being the winter break at UT Austin, I thought I should finish this. My implementation of this (warning: physics student trying to write code) is now merged into the 4.6 branch. I should’ve probably done it before, but yeah, it stretched to fit the time before RC2.

    The only regression I observe with this change over the usual native painting functionality, is that infoboxes flicker when you drag them around. I’m sure that’s a very small thing to trade for the awesome speed and smoothness that GL gives you, when you need it.

    So you can now switch backends at runtime:

    Screenshot explaining how to switch to OpenGL in KStars 2.0.0

    Switching to OpenGL backends at runtime!

    Testing

    We most certainly need a whole lot of testing. Please help the KStars team by seeing if it builds, renders fine, switches backends with no issues, and file any bugs you may have on bugs.kde.org. We will try to fix them before the final tag.

    Thanks for reading.

    Time for me to get back to physics now!

     
    • Martin Gräßlin 7:17 pm on January 2, 2011 Permalink | Log in to Reply

      I just built kstars from trunk and gave it a try with fglrx driver. I am sorry to say that it does not work at all 😦 I only see a white screen and when I start to move the scene I get lot’s of flickering with visible stars in between.

      Btw: which OpenGL version are you targeting?

      • Martin Gräßlin 8:01 pm on January 2, 2011 Permalink | Log in to Reply

        Just tried on my other system with nouveau driver (which renders KWin GLES correctly) and I see some rendering artefacts in the milky way.

        See: http://wstaw.org/m/2011/01/02/plasma-desktoprL2578.jpg

        It does not mean that there is a problem in the rendering, it could as well be a bug in nouveau. Nevertheless it might be worth to look at it 😉

        • Med 8:54 pm on January 2, 2011 Permalink

          If i remember it was reported that it worked fined with mesa’s software rendering. I have no way of testing that easily before the final version is out. Wouldn’t it indicate that the problem is in nouveau? As for the fglrx driver, do you have any clue where the problem might be?

        • Martin Gräßlin 9:13 pm on January 2, 2011 Permalink

          If i remember it was reported that it worked fined with mesa’s software rendering.

          The mesa software rasterizer has nothing to do with the Gallium3D state tracker used in nouveau

          Wouldn’t it indicate that the problem is in nouveau?

          Maybe? Maybe not? Difficult to say. As I have problems with other drivers as well I would not bet on driver bugs.

          As for the fglrx driver, do you have any clue where the problem might be?

          No sorry, I do not know the KStars code at all. So I cannot comment on it.

        • Akarsh Simha 2:56 am on January 3, 2011 Permalink

          Hi

          I want to ask if the QPainter backend works properly on these systems. If that is not the case, this would be release critical, and we may need to revert the entire OGL stuff.

          Can you see the Sky map in QPainter mode with no regressions?

          Regards
          Akarsh

    • Manuel Mommertz 8:24 pm on January 2, 2011 Permalink | Log in to Reply

      With intel graphics, it works very well. I couldn’t see any rendering glitsches. Works quite fast. Though I had to deactivate the rendering of the milky way while moving as this was very slow.

      • Akarsh Simha 2:58 am on January 3, 2011 Permalink | Log in to Reply

        Oh. I haven’t had Milky Way trouble. But when running at 2 minutes / frame speed, I got 16 fps with OpenGL and ~ 6 fps with native painting.

        • Manuel Mommertz 3:12 am on January 3, 2011 Permalink

          milky way is deactivated on move per default. so if you don’t explicitly activated them, you don’t see it 😉
          how do you get the fps numbers?

        • Akarsh Simha 3:22 am on January 3, 2011 Permalink

          Oh, didn’t realize that. I hardly twiddle with the hidden objects settings 🙂
          If you built with debugging, then you’ll see the FPS numbers being written to the console. Maybe we should do something more elegant.

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel