webrender should probably include the shader source directly and not read it from the filesystem

[jrmuizel]

This will make distribution easier and avoids these being user modifiable.

[metajack]

Long term I think this is the plan. But right now this is needed to be able to develop with a reasonable workflow since changing a compiled in shader would require a full servo rebuild.

[metajack]

cc @glennw

[jrmuizel]

Doesn't webrender_traits prevent needing to do a servo rebuild?

[metajack]

webrender_traits prevents a serialization of the dependency tree, allowing more stuff to compile in parallel. You'll still have to rebuild any crates that depend (transitively) on webrender. This probably means you can skip the script crate build, but not the servo crate one (including the final link).

This is a lot of hassle compared to instantaneous shader reload with the file system watcher while running.

[glennw]

It does, but it's still much slower to build and link WR than it is to tweak shaders unfortunately. We do need a solution though that embeds the shaders for distribution.

[metajack]

I assume we'll switch to include_str! at some point, although it would probably be best if there was a cargo feature flag to compile them in or leave them on disk.

[glennw]

I think the plan here would be to have a build step that includes the shader source in WR. By default, WR would use these, however it would also look in a particular location (probably ../webrender/webrender/res/ from the servo directory) and load these as overrides if they are present. This would mean we don't need to copy the shaders to deploy, but still get the benefit of fast iteration time when developing.

[vvuk]

I may do this real quick -- it just bit me (replace'd wr with local version, WR since servo's lock had modified shaders but no version bump), and would make updating WR easier in servo. I'll likely do this with a build.rs step that will collect all glsl files res and generate a .rs file that puts them all in a hash by name.

[staktrace]

FWIW doing this now would be really timely since it's blocking having "runnable" quantum-render builds in automation. (i.e. running these QR builds fails because it can't find the res directory). I can work around it in Firefox build packaging but it would be nicer to not have to.

[matprec]

@vvuk Just curious, why not use include_bytes or include_str instead of a build script which generates source code?

[glennw]

#563