Hi,
> The OpenGL acceleration in Charts module is really impressive ...
Unfortunately part of the truth is, that the performance of the software
renderer does not necessarily be that far behind.
An example: in a test program I'm creating a polygon of 1 points in
an area of 1000x1000 using
Hi,
how about doing the automatic population, but every class is able to
override this by using the "\supports" command.
Maybe it would be also possible to add an link in the Target Platforms
row to the platform overview page of that modules (here qtmultimedia
could document what's available on
On 2016-01-22, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Friday 22 January 2016 18:09:55 NIkolai Marchenko wrote:
>> Speaking of workarounds :
>> I have to use this ugly hack that depends on otherwise inaccessible c=
> ode to
>> update QPrintPreviewDialog
>>=20
>>
Thiago sayeth:
> ,
> But I have no plans on extending QAtomicInteger and QAtomicPointer further.
> There are a couple of missing features that will probably never be
> implemented:
>
> * std::memory_order_consume and std::memory_order_cst
> * GCC's extension for hidden lock elision
> *
On 22-1-2016 22:51, Kevin Kofler wrote:
I'd already be happy with those that were (are, actually) already
there. I'd rather have 10-20 common algorithms with a convenient API
than 80+ obscure ones that force me to use iterators (especially the
boilerplate .begin() and .end() iterators that
On 23-1-2016 17:39, Milian Wolff wrote:
On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote:
Marc Mutz wrote:
And this is where I stop taking you seriously, sorry. You can demand such
nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+
algorithms from the STL for
On Saturday 23 January 2016 17:46:39 Andre Somers wrote:
> On 22-1-2016 22:51, Kevin Kofler wrote:
> > I'd already be happy with those that were (are, actually) already
> > there. I'd rather have 10-20 common algorithms with a convenient API
> > than 80+ obscure ones that force me to use iterators
Hi,
As I promised, I did some benchmarks myself and I got some very surprising
results.
The benchmark code is here: https://github.com/bog-dan-ro/exceptions_benchmark
The benchmark calls a function 10 times and this function trows an
exception/return an error every x calls (x = 100;
On 23/01/2016 12:45, Uwe Rathmann wrote:
Hi,
The OpenGL acceleration in Charts module is really impressive ...
Unfortunately part of the truth is, that the performance of the software
renderer does not necessarily be that far behind.
Now try it against OpenGL with 100k points rendering to
On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote:
> Marc Mutz wrote:
> > And this is where I stop taking you seriously, sorry. You can demand such
> > nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+
> > algorithms from the STL for Qt. Or play god deciding which
On Freitag, 22. Januar 2016 16:47:38 CET Thiago Macieira wrote:
> On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote:
> > I consider the fix of the "have to write '> >' to close double templates"
> > issue as the most useful improvement in the entire C++11 standard.
>
> Not variadic
On Saturday 23 January 2016 19:22:34 Marc Mutz wrote:
> > template < class Container, class Compare >
> > void sort ( Container container, Compare compare)
> > {
> >
> > sort(begin(container), end(container), compare);
> >
> > };
> >
> >
> >
> > Something like that perhaps? Feel free to add
Bogdan Vatra wrote:
> gcc -O2 and -O3 gives the worst/random/surprising results. On the other
> hand, clang (to my HUGE surprise) gives the most consistent results.
That doesn't surprise me all that much. I've seen REALLY strange
benchmarking results from GCC-generated code. In particular, I had
On Sunday 24 January 2016 03:01:57 Kevin Kofler wrote:
> Marc Mutz wrote:
> > On Friday 22 January 2016 20:46:54 Marc Mutz wrote:
> >> Which one is faster? On a dual-core, probably QVector. On a 64-core
> >> processor, probably std::vector.
> >
> > Running attached test program (4 cores + 2-fold
14 matches
Mail list logo