HTML5 video in MinEx (MinimalExample) should "just work"

[jornh]

From the Google Group:

Voila!!! it works. I had to copy ffmpegsumo.dll,libGLESv2.dll,libEGL.dll files which dint come alone with Nuget. But otherwise its all good. Any date for the stable release? (v3.29)

• show quoted text -

So should we just include all the CEF redist pieces?.... Actually it could be a CEF.redist.redist (redist^2) package 😄 because it's a redist of the bits that upstream CEF is redist'ing

[perlun]

See cefsharp/CefSharp#137 for the suggested package names, so you don't have to reinvent the wheel here more than necessary. 😃

[jornh]

I guess you mean this comment: cefsharp/CefSharp#137 (comment)

I'm thinking this on priorities for NuGet partitioning:

1. Size (you generally don't want to transfer and store "big" packages where you only use a small part of it .... So a better term is probably "relative useful size" or "deadweight %")
2. Stability+Coupling - does an update of A always/for the most trigger an update of B - then consider bundling - another case would be A is big and changing slowly - we want to iterate quickly on a small B depending on A
3. It should fit the feature/architectural lines (which you wrapped up nicely in the # 137 comment )
4. Other things ....

Based on this I'm thinking we should maybe split across the x86/x64 pivot dimension instead + maybe a package with the bitness (you can't use that term enough) independent parts? I'm guessing that most either build an app as x86 or x64 - and hence don't need the other libcef.dll big part + other accompanying pieces.

Of course that's seen from a CefSharp using developers PoV (i.e. one building an app based on CEF) and not a CefSharp hacker's

[jornh]

... And it's along the pivot dimension CEF has chosen with "bitness" ... When in Rome do like Romans

[perlun]

I don't know if splitting across bitness would work? I mean, that means that the .vcxproj at the other end will essentially depend on both the packages... hmm, so maybe.

It feels spontaneously a bit wrong to split it based on that. 😃 But I don't know. You are right in that it makes the packages a bit smaller and definitely less "bloated" in a sense. For our particular use case, it's not like we will ever need to support "only one" of them; we always want both x86 and x64. So perhaps we can just optimize for that, and if someone feels like making an x64 app only... well, it's their problem really. 😉

Am I too cruel as a dictator stating that?

[jornh]

Are you aiming for the title of BDFL for CefSharp-land 😉

No seriously; it's great to bounce a bit back and forth on what to do, avoids some of the blind spots - and let's us do it more KISS. Actually I think when I wrote the above I was more thinking about cef.redist the .DLL/.pak package - which also weigh in at a slightly bigger size.

You are right there might be problems when switching bitness when building - but the reason for the error message you get "should" be obvious/already documented in the FAQ if you elected for only e.g. cef.redist.x86 as your dependency - and then tried to build&run an x64.

In general what we gain from splitting across any pivot dimension would be stats versus other stats on what people actually use. Then again, stats are only one of the 3 kinds of lies there are.

Let's take baby-steps and just keep it at what's optimal for CefSharp hackers at first:

• One cef.sdk with all the dependencies (libs + include) for building CefSharp.Core
• One cef.redist with all the dependencies (.dll/.pak) across bitness and with all the HTML5 etc. stuff for executing a CefSharp based app

I will build & push that new cef.redist today/night

[perlun]

Are you aiming for the title of BDFL for CefSharp-land

Why not... 😃 Well, time will tell. Maybe I will hand over the project entirely to you at some time. 😉

No seriously; it's great to bounce a bit back and forth on what to do, avoids some of the blind spots - and let's us do it more KISS. Actually I think when I wrote the above I was more thinking about cef.redist the .DLL/.pak package - which also weigh in at a slightly bigger size.

And to be honest, I didn't really grasp fully your intentions here (cef.sdk and cef.redist for different things). But I understand them now, and I think you're doing good there!

You are right there might be problems when switching bitness when building - but the reason for the error message you get "should" be obvious/already documented in the FAQ if you elected for only e.g. cef.redist.x86 as your dependency - and then tried to build&run an x64.

I think this one is actually quite hard. It's not that easy, not at all. Ideally, I would want it to work like this (and no, this is NOT a short-term goal):

• CefSharp and CefSharp.Core being compiled for Any CPU.
• Depending on the current bitness of the process being run, it would load the CEF binaries dynamically (i.e. no normal reference, but rather by means of LoadLibrary or similar).

The user (of CefSharp) would then not have to care about what bitness they are using. CefSharp would just be smart enough to load the right (unmanaged) binaries as needed.

Wouldn't that be quite cool? If you agree, make this an issue on the CefSharp repo please, and we can then plan it for some future release. It's definitely doable.

So, whatever steps we take here should preferably align with that future roadmap, if possible. I guess that means one single package, or CefSharp depending on both the x86 and x64 packages. But hey - should we perhaps take it even one step further and split depending on VS version...? I mean, to have cef.sdk.vs2010.x86, cef.sdk.vs2013.x64 and so forth? It gives us a lot of packages, but the individual packages becomes much more manageable. It also has the advantage of people like you and @brock8503 being able to contribute/build a package for your specific VS version, and I can then add the VS2010 and VS2012 bits... for example.

Food for thought. What do you think? The difficulty then would just be of course to make the CefSharp dependencies be correct... As a slight side note, I couldn't get the .sln to automatically restore the package (cef.sdk) for me; I don't know why it didn't work. Could you try re-cloning CefSharp and see if it works for you? I mean, from a clean slate...

[jornh]

Food for thought. What do you think?

I think the whole section you wrote above is great actually brilliant thinking "for a NON short-term goal" 😉 that would be two new longer term goals - one here in #6 probably to solve the sdk.vs201*.xNN splitting part (trivial - but useful for the exact reason you mention that cef.sdk can be built piece by piece by those who need it for their own VS201x pivot) - and one cefsharp/CefSharp milestone 3000 ticket for the maybe not so trivial parts on the consuming side.

As a slight side note, I couldn't get the .sln to automatically restore the package (cef.sdk) for me; I don't know why it didn't work. Could you try re-cloning CefSharp and see if it works for you? I mean, from a clean slate...

Now this is something I feel we should be focusing on immediately - because that's the actual blocker for cefsharp/CefSharp#288 being able to land right now (unless you want to focus on getting a non -pre 3.29 out the door before that?). I'll continue it over on cefsharp/CefSharp#288

[perlun]

I think the whole section you wrote above is great actually brilliant thinking "for a NON short-term goal" that would be two new longer term goals - one here in #6 probably to solve the sdk.vs201*.xNN splitting part (trivial - but useful for the exact reason you mention that cef.sdk can be built piece by piece by those who need it for their own VS201x pivot) - and one cefsharp/CefSharp milestone 3000 ticket for the maybe not so trivial parts on the consuming side.

Good. Did you add the issues already? 😉 Btw, should that perhaps be "dimension" rather than pivot?

[amaitland]

This should now work with 1750

[jornh]

Yep! 😄

[amaitland]

😄