[Development] How long until clang memory model is ready?

Chris L hackthegovernment at hotmail.com
Wed Jan 22 19:14:46 CET 2014


There are many people out there that want to use Qt Creator not just for Qt applications but also for general c++ cross platform development as well.When you look at the options available in this area there are only a few with the features set that Qt Creator has.  Eclipse comes to mind. 
Qt Creator could be, with a few fixed bugs the obvious #1 choice ( if it isn't already ) for general cross platform c++ but it seems like the devs ignore non Qt c++ development.  
Which is a shame since people who use Qt Creator for general c++, but haven't coded Qt before would be more likely to pick Qt once they start shopping for a library.  The more people using Qt Creator, the better for Qt.
I brought up the clang memory model because discussions on the irc channels and old blog entries indicate that there was a plan to use clangs memory model to support the stl's classes in Qt Creator ( unique_ptr, vector, ect... ), once clang's memory model was working correctly, and my question is about when to expect this to happen if ever?

> From: development-request at qt-project.org
> Subject: Development Digest, Vol 28, Issue 82
> To: development at qt-project.org
> Date: Wed, 22 Jan 2014 09:03:01 +0100
> 
> Send Development mailing list submissions to
> 	development at qt-project.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.qt-project.org/mailman/listinfo/development
> or, via email, send a message with subject or body 'help' to
> 	development-request at qt-project.org
> 
> You can reach the person managing the list at
> 	development-owner at qt-project.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Development digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: How long until clang memory model is ready? (Thiago Macieira)
>    2. QML Image aliasing when animating (Joshua Kolden)
>    3. Re: QML Image aliasing when animating (Rutledge Shawn)
>    4. Re: QML Image aliasing when animating (Joshua Kolden)
>    5. Re: QML Image aliasing when animating (Gunnar Sletta)
>    6. Re: Remove OSX 10.6 Build? (Ziller Eike)
>    7. Re: Remove OSX 10.6 Build? (Ziller Eike)
>    8. Re: Remove OSX 10.6 Build? (Ziller Eike)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 21 Jan 2014 16:03:21 -0800
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Development] How long until clang memory model is ready?
> To: development at qt-project.org
> Message-ID: <18596554.AqrLlMcojV at tjmaciei-mobl2>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On ter?a-feira, 21 de janeiro de 2014 17:39:07, Chris L wrote:
> > With clang getting complete draft c++14 support, is the memory model
> > sufficient to move to using it by default?  Things like unique_ptr and
> > vector really need this.
> 
> What do you mean? We've been officially depending on the C++11 memory model 
> since sometime in Qt 3. The C++98 memory model is incompatible with threads, 
> we were out of it. There was quite a bit of work to fix some of the issues 
> during the Qt 5.0 timeframe.
> 
> Also, we can't use std::unique_ptr until much later. The Standard Library 
> support is much sketchier than the language support from the compiler. I also 
> don't see a need to use std::unique_ptr at all in Qt code and we don't use 
> std::vector either.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> Url : http://lists.qt-project.org/pipermail/development/attachments/20140121/0ee54eb6/attachment-0001.bin 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 21 Jan 2014 19:03:18 -0800
> From: Joshua Kolden <joshua at crackcreative.com>
> Subject: [Development] QML Image aliasing when animating
> To: development at qt-project.org
> Message-ID: <57AE9A3A-D962-455F-A41F-CACD8056F293 at crackcreative.com>
> Content-Type: text/plain; charset=windows-1252
> 
> I?m getting boxed in with rendering bugs on two fronts.  Originally I tried to work with fonts for the following animation, but have both render quality and font ?subfamily? selection bugs to deal with there. So I took the effort to switch a lot of stuff around and use images instead, however I?m getting aliasing artifacts now.  I?m rather stuck at the moment for rendering a good quality large font design.
> 
> This video shows the aliasing I?m talking about.  There are 3 images here one is 2048x512 and two are 512x512 for the Camera4 and C4 text logos.  The movie is captured pixel for pixel, and the images at their largest (in this example) are smaller then the source resolution.
> 
> http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality.mov
> 
> Here is an example of one of the Image invocations:
> 
>  Image {
>     id: c4CameraImage
>     fillMode: Image.PreserveAspectFit
>     source: ?path/to/c4camera.png"
>     anchors.left: parent.left
>     anchors.top: parent.top
>     anchors.bottom: parent.bottom
>     smooth : true
>     opacity: 0.0
>   }
> 
> The animation is created with a number animation on the width and height of the parent rectangles.
> 
> I?ve asked on IRC, and in the [interest] list, but one said it should just work and the other didn?t reply.
> 
> Is this a known issue, a bug, or and I?m I doing it wrong?  
> 
> Thanks,
> j
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 22 Jan 2014 07:21:28 +0000
> From: Rutledge Shawn <Shawn.Rutledge at digia.com>
> Subject: Re: [Development] QML Image aliasing when animating
> To: Joshua Kolden <joshua at crackcreative.com>
> Cc: "<development at qt-project.org>" <development at qt-project.org>
> Message-ID: <DF10430D-7FBE-4D8A-BFA0-9B1236F4EAA7 at digia.com>
> Content-Type: text/plain; charset="Windows-1252"
> 
> 
> On 22 Jan 2014, at 4:03 AM, Joshua Kolden wrote:
> 
> > Image {
> >    id: c4CameraImage
> >    fillMode: Image.PreserveAspectFit
> >    source: ?path/to/c4camera.png"
> >    anchors.left: parent.left
> >    anchors.top: parent.top
> >    anchors.bottom: parent.bottom
> >    smooth : true
> 
> Did you try antialiasing: true?  
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 21 Jan 2014 23:25:50 -0800
> From: Joshua Kolden <joshua at crackcreative.com>
> Subject: Re: [Development] QML Image aliasing when animating
> To: Rutledge Shawn <Shawn.Rutledge at digia.com>
> Cc: "<development at qt-project.org>" <development at qt-project.org>
> Message-ID: <5E47AE2F-4778-4B0F-97D3-3341A794F7F6 at crackcreative.com>
> Content-Type: text/plain; charset=windows-1252
> 
> Yes, it also has no effect.
> 
> 
> On Jan 21, 2014, at 11:21 PM, Rutledge Shawn <Shawn.Rutledge at digia.com> wrote:
> 
> > 
> > On 22 Jan 2014, at 4:03 AM, Joshua Kolden wrote:
> > 
> >> Image {
> >>   id: c4CameraImage
> >>   fillMode: Image.PreserveAspectFit
> >>   source: ?path/to/c4camera.png"
> >>   anchors.left: parent.left
> >>   anchors.top: parent.top
> >>   anchors.bottom: parent.bottom
> >>   smooth : true
> > 
> > Did you try antialiasing: true?  
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 22 Jan 2014 07:50:38 +0000
> From: Gunnar Sletta <gunnar.sletta at jolla.com>
> Subject: Re: [Development] QML Image aliasing when animating
> To: Joshua Kolden <joshua at crackcreative.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID: <5EF03F70-2C0D-4668-9B34-86961177488F at jollamobile.com>
> Content-Type: text/plain; charset="Windows-1252"
> 
> This is the expceted result. smooth: true uses bilinear filtering which is what is supported in hardware. When scaling down, this starts to degrade. The effect is drastic for high-contrast content like the edges of a font. Once go get below 0.5x scale factor the sampling starts to ignore pixels and aliasing become very visible. 
> 
> The preferred solution is to prepare raster content (images in your case) close to the size you intend to show them. If you must scale them down, then use mipmapping. With the image element, you can get this by doing:
> 
> Image {
>     layer.enabled: true
>     layer.smooth: true
>     layer.mipmap: true
>     ...
> }
> 
> However, by enabling the layer you get an extra texture copy of your rather large image, so it might be preferable to implement a custom QQuickItem which returns a QSGSimpleTextureNode with a QSGTexture with mipmapping.
> 
> cheers,
> Gunnar
> 
> On 22 Jan 2014, at 04:03, Joshua Kolden <joshua at crackcreative.com> wrote:
> 
> > I?m getting boxed in with rendering bugs on two fronts.  Originally I tried to work with fonts for the following animation, but have both render quality and font ?subfamily? selection bugs to deal with there. So I took the effort to switch a lot of stuff around and use images instead, however I?m getting aliasing artifacts now.  I?m rather stuck at the moment for rendering a good quality large font design.
> > 
> > This video shows the aliasing I?m talking about.  There are 3 images here one is 2048x512 and two are 512x512 for the Camera4 and C4 text logos.  The movie is captured pixel for pixel, and the images at their largest (in this example) are smaller then the source resolution.
> > 
> > http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality.mov
> > 
> > Here is an example of one of the Image invocations:
> > 
> > Image {
> >    id: c4CameraImage
> >    fillMode: Image.PreserveAspectFit
> >    source: ?path/to/c4camera.png"
> >    anchors.left: parent.left
> >    anchors.top: parent.top
> >    anchors.bottom: parent.bottom
> >    smooth : true
> >    opacity: 0.0
> >  }
> > 
> > The animation is created with a number animation on the width and height of the parent rectangles.
> > 
> > I?ve asked on IRC, and in the [interest] list, but one said it should just work and the other didn?t reply.
> > 
> > Is this a known issue, a bug, or and I?m I doing it wrong?  
> > 
> > Thanks,
> > j
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 22 Jan 2014 07:51:53 +0000
> From: Ziller Eike <Eike.Ziller at digia.com>
> Subject: Re: [Development] Remove OSX 10.6 Build?
> To: Mohamed Fawzi <Fawzi.Mohamed at digia.com>
> Cc: Sorvig Morten <Morten.Sorvig at digia.com>,
> 	"<development at qt-project.org>" <development at qt-project.org>
> Message-ID: <7F74D3A7-3D0C-4F60-A229-CE6278B609A6 at digia.com>
> Content-Type: text/plain; charset="Windows-1252"
> 
> 
> On Jan 21, 2014, at 3:01 PM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
> 
> > 
> > On 21 Jan 2014, at 14:25, Jake Petroules <jake.petroules at petroules.com>
> >  wrote:
> > 
> >> On Jan 21, 2014, at 7:36 AM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
> >> 
> >>> On 21 Jan 2014, at 11:51, Simon Hausmann <simon.hausmann at digia.com> wrote:
> >>> 
> >>> That depends on how much time we spend releasing Qt :) 
> >>> 
> >>> I realize that if I?m the only one who want?s to keep supporting 10.6 then that?s not going to work. The most important thing to me is to have a somewhat predictable deprecation plan. For example (and at the risk of making this example ?the plan?):
> >>> 
> >>> 5.3 - Remove support from binary packages.
> >>> 5.4 - 10.6 support is deprecated.
> >>> 5.5? - Remove support.
> > 
> > I also think that it looks reasonable, but I would also find announcing now that 5.4 drops 10.6 support ok (I don't see this big need for "deprecated but still there" if one knows long enough before).
> > Anyway another thing (with ARC support) is also C++11.
> > Is it clear when we will begin to require C++11?
> 
> > Because supporting C++11 in 10.6 is *very* tricky (one might try to ship libc++, but system library will still use libstdc++ and I am not sure if binary compatibility with the version shipped in 10.6 is guaranteed.
> 
> You can?t compile C++11 code if you use deployment target 10.6 (the Apple tools prevent that), so ?ship libc++? is out of question. The only maybe-possible path would be to use custom GNU libs instead of the Apple-provided ones, but I do not think that we want to support that in any way.
> 
> ++ Eike
> 
> > Fawzi
> >> 
> >> I think this is relatively reasonable. By 5.5 (mid-2015, right?) we will have or almost have OS X 10.11 which is three versions into the OS X free pricing model. Given the fast uptake of OS X Mavericks in just a few short months, by then it seems to me that it will be the ideal time to say goodbye to the last of the Leopards. The gap between Snow Leopard and Lion is also probably the most technically significant between any two recent versions of OS X, so when it's 10.7's time to go we may not even need any code changes.
> >> [...]
> > 
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> Eike Ziller, Senior Software Engineer - Digia, Qt
>  
> Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Tuula Haataja
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 22 Jan 2014 07:53:23 +0000
> From: Ziller Eike <Eike.Ziller at digia.com>
> Subject: Re: [Development] Remove OSX 10.6 Build?
> To: Sorvig Morten <Morten.Sorvig at digia.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID: <FFFFEEBB-4BD5-4566-81E3-AB5744AD50EC at digia.com>
> Content-Type: text/plain; charset="Windows-1252"
> 
> 
> On Jan 21, 2014, at 3:15 PM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
> 
> > On 20 Jan 2014, at 21:21, deDietrich Gabriel <Gabriel.deDietrich at digia.com> wrote:
> >> The truth is, market share doesn?t mean anything. Point in case: According to the link above, OS X is less than 8% of the total market share. Should we then drop the Mac port completely?
> > 
> > Good question! Possible arguments for not discontinuing the Mac port:
> > 
> > - The holistic view. The single platform is not that important, but as a part of a comprehensive platform support package it becomes valuable.
> > - The 8% OS X users represent a group we want to target.
> > - We can use the Mac port to make Qt better. Case in point the high-dpi support developed for OS X can be used on Wayland as well.
> 
> - A good part of the OS X port is useful for the iOS port, and on the smartphone market the numbers are pretty different
> 
> -- 
> Eike Ziller, Senior Software Engineer - Digia, Qt
>  
> Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Tuula Haataja
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 22 Jan 2014 08:02:59 +0000
> From: Ziller Eike <Eike.Ziller at digia.com>
> Subject: Re: [Development] Remove OSX 10.6 Build?
> To: Vestbo Tor Arne <tor.arne.vestbo at digia.com>
> Cc: Sorvig Morten <Morten.Sorvig at digia.com>,
> 	"<development at qt-project.org>" <development at qt-project.org>
> Message-ID: <E567ACC5-63B2-4169-8D9D-F2AF68E8DCB7 at digia.com>
> Content-Type: text/plain; charset="Windows-1252"
> 
> 
> On Jan 21, 2014, at 2:56 PM, Tor Arne Vestb? <tor.arne.vestbo at digia.com> wrote:
> 
> > On 21/01/14 13:36 , Sorvig Morten wrote:
> >> I realize that if I?m the only one who want?s to keep supporting 10.6
> >> then that?s not going to work. The most important thing to me is to
> >> have a somewhat predictable deprecation plan. For example (and at the
> >> risk of making this example ?the plan?):
> >> 
> >> 5.3 - Remove support from binary packages. 5.4 - 10.6 support is
> >> deprecated. 5.5? - Remove support.
> > 
> > 5.3:
> > 
> >  - Remove support from binary packages
> >  - No CI
> >  = In practice, deprecated, so let's be explicit about it for 5.3
> > 
> > 5.4
> > 
> >  - Bump the dev branch to 5.4
> >  - Remove 10.6 code as see fit
> >  - Apply 10.6 fixes to 5.3.x (stable) as normal
> > 
> > The message is "Qt 5.3 deprecates 10.6 support (but is available for 
> > source builds for the lifetime of 5.3), and 5.4 will remove it.?
> 
> I?d support this plan, and additionally throw in:
> 
> after 5.3 / Qt Creator 3.2:
>  - drop support for compiling & running Qt Creator on 10.6
> 
> We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don?t necessarily need to keep ?its IDE? running there (yes, that?s a Qt-centric way of looking at Qt Creator).
> 
> Br, Eike
> 
> -- 
> Eike Ziller, Senior Software Engineer - Digia, Qt
>  
> Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Tuula Haataja
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> End of Development Digest, Vol 28, Issue 82
> *******************************************
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140122/9993b978/attachment.html>


More information about the Development mailing list