You can always render the text to a texture offline as a signed distance field and just draw out quads as needed at render time. This will always be faster than drawing from the curves, and rendering from an SDF (especially multi-channel variants) scales surprisingly well if you choose the texture/glyph size well.

A little more info:

https://blog.mapbox.com/drawing-text-with-signed-distance-fi...

MIT-licensed open-source multi-channel glyph generation:

https://github.com/Chlumsky/msdfgen

The only remaining issue would be the kerning/layout, which is admittedly far from simple.

Only in the random case. Already sorted in either direction and it's ~10x slower.

Who wants to sort sorted data. If the input data is more often sorted, you can test this before sorting.

Data can be partially sorted and it happens quite often. As I understood, it's exactly the purpose of quadsort - to leverage locally ordered sequences.

Sort your data. Store it somewhere and then later add more unsorted data.

Sorting sorted or mostly-sorted arrays is not uncommon in many use cases.

Usually what people mean by mostly sorted in CS is that there is some small K such that each element in the input is no more than K places from the position it would be in if the input was sorted.

According to this definition, the "random tail" test data is not "mostly sorted".

Well you could extend the definition to allow a small number of items which are entirely out of place. The point is that the right sort algorithm depends a lot on tthe distribution of input data and how much you care about worst-case vs average case trade offs.

The bill is not split -- it says they reimburse you for the measured power usage of the device. Nowhere does it say that this only applies when the heat is being directed into your house, that I could see.

Apart from the point in the first video when they click on a link and you can still see the smudge of the text column on the newly cleared screen. A close look at the text column while scrolling makes it look dirty compared to the rest of the screen as well.

Most of it was readable, but the printf on lines 57--59 made me retch. I see what it's doing, but it's not what I'd call easily maintainable:

  printf("%8.4s", &"LEA ,IMM ,JMP ,JSR ,BZ ,BNZ ,ENT ,ADJ ,LEV ,LI ,LC ,SI ,SC ,PSH ,"
         "OR ,XOR ,AND ,EQ ,NE ,LT ,GT ,LE ,GE ,SHL ,SHR ,ADD ,SUB ,MUL ,DIV ,MOD ,"
         "OPEN,READ,CLOS,PRTF,MALC,MSET,MCMP,EXIT,"[*++le * 5]);

I'd like to know why this was downvoted, and if people who down voted it can explain what the code is doing please?

It's taking an integer (representing an operation) and printing out the name of that operation.

First thing to say is that "* ++le" is the integer representing the operation to perform. This basically walks through the array of instructions returning each integer in turn.

Starting at the beginning of the line, we have "printf" with a format string of "%8.4s". This means print out the first 4 characters of the string that I pass next (padded to 8 characters). There then follows a string containing all of the operation names, in numerical order, padded to 4 characters and separated by commas (so the start of each is 5 apart). Finally, we do a lookup into this string (treating it as an array) at offset "* ++le * 5", i.e. the integer representing the operation multipled by 5 (5 being the number of characters between the start of each operation name). Doing this lookup gives us a char, but actually we wanted the pointer to this char (as we want printf to print out this char and the following 3 chars), so we take the address of this char (the & at the beginning of the whole expression).

It's concise, but not exactly self-documenting.

Does that make sense?

(I didn't downvote.)

How is that not self-documenting if one knows C?

I think you and I might disagree on the meaning of self-documenting. ;)

I don't think we really do.

It is impenetrable black magick if one "knows" C -- but quite clear if one /actually/ knows C.

Ah, the No True Scotsman finally arrives to the party.

No. The printf() requires that one has read K&R. That's not a high barrier to clear. Pointers are chapter 5.

It looks like a nice test framework, but it doesn't appear to help at all with the really hard problems you face with testing C++ -- isolating the unit under test for separate compilation, and the development and inclusion of mocks/stubs.

Anyone know of a really good (preferably simple and pragmatic) C++ mocking/stubbing framework to go with this?

Why do you want to compile the unit test separately?

Because that's what makes it a unit test -- you only want the unit, the tests and any stubs/mocks in the executable. Anything more and you have an integration test on your hands.

Pulling a single unit out of a legacy codebase can be difficult, especially when you don't want to actually move, copy, or modify the source-files; stubbing out the dependencies and writing mock objects to verify your expectations of what the code should be doing are also very time-consuming.

Those are the hard parts of unit testing C++, and I wonder if anyone has found a good way of doing it (with a framework, or just a technique).

> Thus - at the same bitrate - higher resolution images might look worse than lower resolution ones.

But the 4K stream is HEVC (H.265) vs H.264 for the other HD streams, so it may not be that simple.

Well, HEVC compresses the same quality to about half the size of H.264, so since 4K is about 4x 1080p and the bitrate is a little over 2x their 1080p Super HD streams I'd expect the quality to be a little better.

What I'd really be interested to see is the House of Cards intro at this bitrate - the 1080p Super HD stream had a lot of really off-putting banding in the clouds.

> HEVC compresses the same quality to about half the size of H.264

Eh, it's supposed to, but it's not there yet. The best H.264 encoder (x264) is actually still more efficient than the best H.265 encoders (and MUCH faster).

Development of the H265 encoders is progressing fast though, x265 will likely surpass x264 within the year.

Here's some recent samples (12th June) that compares a very recent build of x265 with x264: http://forum.doom9.org/showpost.php?p=1683608&postcount=907

Apple did just release online versions of the iWork apps with collaboration (I don't know how well it works in real-time, but then I don't know that for Office either). They also made fun of the MS equivalent in their keynote.

I'm sure that's unrelated :-)

This seems specific to image-based fingerprint sensors? Apple's version does not appear to work this way...

Average speed checks are awful — I spend more time looking at the speedo than I do the road, as I try to keep close to the limit while not hitting the car in front. And they are always for odd speeds that I find difficult to maintain (just the wrong pedal position).

Perhaps they make sense when everyone has cruise control as standard to rely on, but until then a mass rollout would drive me to public transport. Or is that the point?