Ion: Cross-platform OpenGL library from Google • Hacker News Board

Re: Ion: Cross-platform OpenGL library from Google

#41

Post by autoreleasepool » Wed, Feb 10, 2016, 10:16 PM UTC

pjmlp wrote: post #30

pcwalton wrote: post #17

Earlier quoted context omitted.

I'm not exactly a fan of C++, but this isn't fair. What you're describing is more of a problem with this project's coding style than the language. Most of https://github.com/google/ion/tree/master/ion/base is covered either by the STL or Boost; most of what the C++ committee has been doing lately consists of trying to encourage people to not do what this project is doing (by improving the breadth of the standard libr…

I have seen the C sub-community of C++ obsessed with things like what makes the compiler generate more optimized code, i++ or i = i + 1. This goes for every code line that one writes, most of the time backed up by urban legends and popular beliefs instead of profiling the code. Whereas other programming languages cultures, tend have a more meaningful approach to optimizing software.

I know a guy who works at an airline company. He's porting all the C++ and assembly code to 64 bit architecture. He genuinely did not know C++ was a seperate language from C.

To be fair, he shamelessly bragged about getting the job through nepotism.

Re: Ion: Cross-platform OpenGL library from Google

#42

Post by pierrec » Thu, Feb 11, 2016, 2:51 AM UTC

ricardobeat wrote: post #39

pierrec wrote: post #10

Neat. This and Oryol [1] appear to have similar goals, I think this already calls for a more in-depth comparison... Either way, this kind of technology could end up being a better choice than the node-webkit / electron paradigm, for many projects that want to target in-browser and native platforms. I've been planning a project like that using raw GL, but with these frameworks popping up, the concept might go from exp…

The main advantages of electron are html, css and javascript. This is not going to be an alternative to it unless you implement a browser engine on top of it, going full circle... On the other hand, something like react-native for desktop, coupled with a nice GUI library, could be very interesting.

Sure, this will never be a 100% alternative to electron. People who derive pleasure from writing HTML, Javascript, and CSS whenever possible will never stray from that kind of framework. As you say, some also choose these frameworks because of the extensive browser API features. However, some people who don't particularly appreciate these languages and API still use electron because it allows them to target browser and native with a single code base. This is where things might change.

The sad fact is that most electron applications only use a small fraction of the massive featureset provided by a full browser, and whenever a tiny GUI application gets forcibly bundled with 70+MB of browser runtime, a cute fluffy animal dies. I think this new kind of framework has the potential to save some cute fluffy animals in the long term, though certainly not all of them.

Re: Ion: Cross-platform OpenGL library from Google

#43

Post by aledalgrande » Thu, Feb 11, 2016, 2:54 AM UTC

Wish there was something cross-platform like this, but with the syntax, tooling, performance and compute shaders of Metal.

Re: Ion: Cross-platform OpenGL library from Google

#44

Post by imron » Thu, Feb 11, 2016, 8:28 AM UTC

pjmlp wrote: post #29

imron wrote: post #18

Earlier quoted context omitted.

To provide performance improvements that you don't get using the built in facilities. You don't have to write these things yourself, but if you're trying to eke out every last drop of performance (either at runtime or build time) then you have the option to do so.

Many times it is to get the performance improvements you think you should need, but actually never will. Having been coding since the days of Assembly being a normal language for business applications, I never seen a programming community so obsessed with micro-optimizations per code line, (without using profilers, because programmer knows best), like the C one. And by correlation the C sub-communities from C++ and O…

I agree that micro-optimization obsession is a problem in the C++ community, but sometimes it is useful and then it's nice to have the option.

Personally, I have my own custom hashmap which provides a 10%-15% performance improvement over the std one for my use case, and I also have custom mutex/thread code similar to the one listed in this library because it provides better performance when no other thread has the lock, and avoids needing to compile/link against the boost equivalent which adds seconds of compile time to any file that includes it.

These are all optimisations that I have tested and profiled though.

Re: Ion: Cross-platform OpenGL library from Google

#45

Post by pjmlp » Thu, Feb 11, 2016, 8:56 AM UTC

imron wrote: post #44

pjmlp wrote: post #29

Earlier quoted context omitted.

Many times it is to get the performance improvements you think you should need, but actually never will. Having been coding since the days of Assembly being a normal language for business applications, I never seen a programming community so obsessed with micro-optimizations per code line, (without using profilers, because programmer knows best), like the C one. And by correlation the C sub-communities from C++ and O…

I agree that micro-optimization obsession is a problem in the C++ community, but sometimes it is useful and then it's nice to have the option. Personally, I have my own custom hashmap which provides a 10%-15% performance improvement over the std one for my use case, and I also have custom mutex/thread code similar to the one listed in this library because it provides better performance when no other thread has the lo…

Which is all fine if you are coding for scenarios where every ms counts like you say.

The problem I see is when doing applications where doing the work in 100ms or 1s doesn't matter at all.

Yet one will be discussing about bounds checking impact, if i++ or i = i + 1 generate the same code and many other micro-optimizations.

For the type of work I do, I always embraced the STL and never though a second about those issues, yet I was able to fulfill the expectations.

Re: Ion: Cross-platform OpenGL library from Google

#46

Post by joeld42 » Fri, Feb 12, 2016, 7:03 AM UTC

kengonakajima wrote: post #34

Build fails in Yosemite inside zlib. I forked it and trying to fix it.. Anyone did?

I don't really understand their build system so not sure how to fix this cleanly but I added:

#define NOCRYPT (1) #define NOUNCRYPT (1) at the top of ./third_party/zlib/src/contrib/minizip/zip.c and unzip.c

And that got past the zlib errors on yosemite and built some of the demos (I will post some screenshots on twitter @joeld42, but it's just boxes and stuff). However, there was a linker error later with some json parser (maybe it was in the tests? I can't even tell) that I didn't figure out yet.

I also had to install "ninja" because apparently it needs like six different build systems.

The "ios" targets build... but I don't know what to do with them. I ended up with a directory full of .app files. Maybe zip them and rename them ipa?

Anyways, it looks like there's some cool stuff in there but there's a ton of dependencies and it doesn't really feel "lightweight". I'll definitely keep an eye on this one but it really could use more documentation for people not familiar with google's ecosystem.