discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User experience


From: Ivan Vučica
Subject: Re: User experience
Date: Thu, 02 Jan 2014 18:15:06 +0000

The patch is no longer required as Eric has helped by renaming the relevant classes when I was doing this year's GSoC project.

Sadly I don't know about the fonts issue; they should be drawn by Opal / Core Graphics. The relevant thing is done in the demo anyway, and not in QuartzCore code itself, so if you can figure out a way to draw fonts -- a patch will we very welcome :-)

(This is because I cannot work on QC right now, so I can't look into the issue. I will help with my thoughts and advice in any way I reasonably can, though.)

On Thu Jan 02 2014 at 9:40:20 AM, Tom Bruno <thomas.bruno@me.com> wrote:
I'm currently looking and interested in the quartzcore project. I've been reading through the source and all the threads that I can find.  I've been able to compile, install & run the demos but have a few questions.  I see your notes about opal requiring your opal-nsfonthacks.patch.  It seems this patch can no longer apply. In addition to that issue, it also seems that when I run all the demo fonts are not visible.  I'm currently using clang-3.4 and a self build of svn trunk for all modules/libs etc.

  Tom


On Dec 24, 2013, at 6:44 AM, Ivan Vučica <ivucica@gmail.com> wrote:

Hi Riccardo,

On Mon Dec 23 2013 at 4:09:33 PM, Riccardo Canalicchio <riccardo.canalicchio@gmail.com> wrote:

Ok, I can help on the shaders field or the frame scheduling ( I'm not really experienced with xorg) the upstream is on svn? I need to study the current code... 

Yes, all the code you want is on SVN. See the 'quartzcore' directory (we really need to rename this).

Do you have any paper of the overall design of CoreAnimation?

There is no such paper. It took me a while to figure out how best to implement Core Animation while staying compatible; in fact, that is an even more important part of my GSoC2012 work than the actual implementation itself.

The implementation itself is the documentation, and I tried to iron out even the edge cases. Sadly, there are still cases where even the timing implementation that's in our code isn't fully compatible, but you'll notice that only in edge cases. And if someone is depending on Apple-compatible behavior, well, we can think about it when it's reported.

Currently gnustep seems to have not a roadmap but this project has one?

Not really, but it has a list of things you need if you want to make our implementation actually useful.

Just another question are you sure to use directly opengl?

I'm completely sure.

For example Clutter uses CoGL that wraps opengl and make a common api between opengl and opengles; skia also supports both opengl and gles... i have seen a lot of mails talking about uikit but opengl is not supported on mobile...

Clutter is a scene manager, like Core Animation. Let's not include a middleware that doesn't need to be there. That goes for any other API wrappers; Core Animation API itself is a wrapper around OpenGL.

Skia is, to the best of my knowledge, a Cairo and Core Graphics analogue, and deals primarily with rendering of 2D primitives. Core Animation deals with exposing compositing, 3D transforms and filtering to an Objective-C application in a nice API which supports implicit creation of CAAnimation objects. Skia could be used to provide content for CALayers, but there is no need to; we have Opal (our implementation of Core Graphics) for that.

And regarding OpenGL not being supported on mobile, I'd advise you to compare the API of OpenGL and OpenGL ES. You'll see a lot of similarities. In fact, as David said, if you write OpenGL ES code, you need to do only minimum adaptations.

At one point I had OpenGL ES compatibility in GNUstep's implementation of CA; I didn't test it in a long time by the time I wrapped up the GSoC project. In fact, it almost certainly doesn't work, considering that I added (very dumb and slow) shadow support by using shaders, which aren't supported in OpenGL ES 1.x, but are supported in OpenGL ES 2.0. The solution would be to transition to OpenGL ES 2.0, which would require use of (simple) shaders everywhere, as ES 2.0 tried to do away with as much of fixed function pipeline as possible; it's not a big deal, but it would take (only?) a few hours.


On Tue, Dec 24, 2013 at 1:05 AM, Lundberg, Johannes <johannes@brilliantservice.co.jp> wrote:
Hi

As you know, CG and CA is definitely a necessity for our project. As soon as I can get my hands on someone who knows their ways around Open[GL/CL/VG] etc I will put them to work on helping you implementing this in GNUstep :)

--
Johannes Lundberg

I'll be more than happy to provide initial planning and advice, as well as (pending positive resolution of some paperwork) code :-)

OpenGL and OpenGL ES knowledge is probably enough, no need to worry about OpenCL and OpenVG.

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

reply via email to

[Prev in Thread] Current Thread [Next in Thread]